
Amazon Aurora PostgreSQL Serverless - sahin-boydas
https://aws.amazon.com/blogs/aws/amazon-aurora-postgresql-serverless-now-generally-available/
======
icheishvili
Our experience with pg aurora was awful. I cannot recommend it to anyone. Our
primary would run out of memory and fail over every few hours and all amazon
support had to say is that it’s a known issue.

We ended up adding even more functionality to our audit trigger package (based
on a SecondQuadrant fork, [https://github.com/icheishvili/audit-
trigger](https://github.com/icheishvili/audit-trigger)) to allow us to get off
of aurora. AWS does a good job at locking you in.

~~~
js2
Here's another recent report of a bad experience with a reply from the
Principal Product Manager for Aurora PostgreSQL:

[https://www.reddit.com/r/aws/comments/bv70k8/aurora_postgres...](https://www.reddit.com/r/aws/comments/bv70k8/aurora_postgres_disastrous_experience/)

------
sudhirj
At the risk of sounding like an AWS apologist, this is really great if you
have a use case for it. Don’t use it if you don’t.

We’ve been waiting to use this for our dev and test environments - the devs
and testers work irregular schedules, sometimes only a few hours a day and
obviously 5 days a week. We currently have manual and semi automatic start and
stop switches for those environments, can get rid of all that.

Some of our systems are low volume high value - they kick into high gear once
or twice a week (not necessarily on a schedule, whenever customers feel like
placing and order) at which point hundreds of thousands of queries need to be
run. We currently run large or extra large DB servers 24x7 at 0.01% overall
utilisation because of this.

Some of the services are used only during daytime at a single timezone, but
once in a while there are a few night owls.

It’s perfect for use cases like this. Sure, if you compare it cost wise to a
similar 24x7 instance it’ll be more expensive. Sure, it takes lots of seconds
at for a cold boot. Both these things are not the point. The tool is what it
is, and it’s clear about its shortcomings in the same way that a Gatling gun
is clear that it has a non negotiable spin up time. That doesn’t mean it’s not
useful, it needs to be matched to the work it can do effectively.

------
don_neufeld
Add me to the chorus of those with severe Aurora Postgres regrets. We are in
the process of shutting down a very large installation of it.

I strongly discourage use of this product. It has serious problems that
serverless does not fix.

~~~
gmueckl
Could you name some of these problems?

------
iamed2
In response to some of the complaints about Aurora PostgreSQL in this thread:

Aurora PostgreSQL Serverless should be considered a different product with
different performance characteristics. We've been experimenting with Aurora
PostgreSQL and have encountered the same memory issues mentioned here and
elsewhere. It's impossible to autoscale read replicas based on memory usage,
and there's no swap for temporary spikes. We haven't yet seen those problems
with Aurora PostgreSQL Serverless. There is swap, which handles spikes, and
whatever automatic scaling Amazon has implemented adequately deals with
increased memory usage (if you're okay with a few terminated connections). I
can't comment on the index-related issues, but I do suggest considering this
product separately from Aurora PostgreSQL.

~~~
icheishvili
The index related issues themselves should be a show stopper. I couldn't
believe it until I ran into other people saying the same thing, but having
secondary indices on your tables slows writes down by something like an order
of a magnitude.

I've yet to see an OLTP system that doesn't use secondary indices on tables.
And if your workload is OLAP, there are far better relational tools.

------
dstaley
The biggest roadblock to me using Aurora Serverless is cold start times. Last
time I checked it was over 20 seconds.

~~~
incadenza
I experienced this with Lambdas behind a VPC, and yeah it's completely crazy.
This is true with the DB offerings as well?

I don't see what the use case is then. Intermittent background jobs or
something?

------
strin
Aurora Database + auto-scaling #instances = Serverless??

~~~
cowsandmilk
No, that was Aurora Autoscaling[0]. Is there an actual difference in
implementation? Not sure, but there are many limitations in serverless not
present with aurora auto scaling[1].

[0]
[https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html)

[1]
[https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-
serverless.html#aurora-serverless.limitations)

------
truth_seeker
I wish it allowed to install community extensions which are not part of core
software.

------
atonse
Can anyone comment on how this compares to CitusDB? Probably is a lot more
expensive?

How about things like support for PostGIS, etc? Is that moot since Aurora is
mostly at the storage layer?

~~~
olefoo
Citus is a fork of Postgresql and you would need to run it on it's own
infrastructure.

AWS Aurora Postgresql regular flavor does support some of the popular
extensions but that may not be the case with this flavor since it has some
memory, image space and execution time limits that the other managed Aurora
solution would not.

That said, being able to keep a pool of warm database clients at the ready for
unpredictable write loads looks like it would be a winner and AWS has reliably
improved to add requested features.

~~~
daurnimator
Citus isn't a fork any longer, it's just an extension.

------
sidcool
I have a basic question here. While RDS manages everything that we typically
need, how is it different from the Serverless counterpart in the form of
Aurora Postgres here?

------
mbesto
Curios - what's the use case for a Serverless DB?

~~~
davnicwil
It says it's ideal for unpredictable load or infrequent demand. My reading is
that billing is done per minute only while the database is being read /
written to (active), but what I'm not sure about is if the storage is
completely free whilst it's inactive. If that's the case it would seem like a
great solution for BI and analytics type applications where you want to
collect data over time (and are able to batch writes) and produce reports
relatively infrequently.

~~~
013a
The storage is definitely not free, even while inactive.

