[mattgibson]

For clarity, there is a significant warm up time for the DB to load your data when you cold-start, so this is sadly not suitable for use with serverless lambda functions in a web request cycle.

A good use case for this would be batch processing on demand e.g. a background job that's infrequently run when records are uploaded somehow. You save the cost of keeping a big DB running in between jobs and the start up time doesn't matter.

[sudhirj]

Also note that you don’t necessarily have to scale down all the way to zero. Also works for workloads that are very spiky, like breaking news or weekend or work hours heavy loads.

[jjeaff]

If pricing is similar to other serverless offerings at AWS, then it will cost much more to run it constantly at low rates than to just run a small instance all the time. But maybe the much faster scale up would be desirable in some cases.

[BenoitP]

What kind of time are we talking about, 10 seconds or 3-4 minutes?

Or very short, but everything will be painfully slow?

[sudhirj]

On the order of tens of seconds, for a cold start from zero. Enough time to load your RAM cache from hibernation and boot up OS and Postgres.

[boarnoah]

Is it really? Been trying out Aurora MySQL for our staging db, and its closer to 1 min+ for a cold start.

[sudhirj]

But isn’t the variance on this completely useless? It’ll depend entirely on the size of your cache, the region you’re in, the traffic at that time and rack you’re lucky enough to be on. Will also depend on AWS configs, which can change daily.

[jjeaff]

But what does it mean to be warm in this case? Last called less than a minute ago? 10 minutes?

[crb002]

Is their a hook on spin down? You could send a small read only cache to a S3 SQLite file so lambdas will have a failover on long reads.

[eloff]

Just don't let it spin all the way down. Scaling up and down is better.