4 ms·
I can't wait for the day when we figure out how to "scale to zero" with database engines and also still provide quick starts. The serverless model is fantastic
by dstaley 8y ago
I can't wait for the day when we figure out how to "scale to zero" with database engines and also still provide quick starts. The serverless model is fantastic for smaller projects that can't justify the monthly cost of RDS. I was super excited about Aurora Serverless until I found out cold starts take about 30 seconds, and even longer if you use a VPC to connect to it from a Lambda function. The single table approach with DynamoDB would work, but the amount of cognitive effort necessary compared to just using a relational database isn't worth it for small toy projects.
- jchanimal 8y agoFaunaDB (my employer) scales from zero to worldwide, with no pre-provisioning or capacity planning required. In addition to serverless database pricing and no cold start, you get full ACID transactions as well as relational features. None of the overloading of shard keys etc as featured in the DynamoDB video.
- Drdrdrq 8y agohttps://fauna.com/ https://fauna.com/
- 013a 8y agoThe easiest solution, which is quite easy, at least for Aurora Serverless/Lambda: Cron a warming function that calls something in the cold service every 5 minutes. This should add literally pennies, if that, to the total cost and is relatively effective. Of course, it isn't "scale to zero", its just never letting it go to zero. But the practical and financial difference is almost nothing.
- dstaley 8y agoIf I remember correctly, the pricing model for Aurora Serverless is different from Lambda in that you pay as long as the engine is running, whereas with Lambda you only pay when the function is executing. Keeping an Aurora Serverless instance warm would then cost $43/month.
- thesandlord 8y ago(I work for Google Cloud) Many various GCP databases (most notably Firestore[0], and Datastore[1] before it) do this today. No provisioning, pre-warming, or capacity planning needed. [0] https://firebase.google.com/docs/firestore/ https://firebase.google.com/docs/firestore/ [1] https://cloud.google.com/datastore/ https://cloud.google.com/datastore/
- dstaley 8y agoThanks for sharing! I really should have been more specific and said "SQL database engines". There's definitely a lot of interesting work going on in the document store space, but as someone who's more familiar with SQL relational databases it's always a challenge to fit my data model into the constraints of document-based datastores. For example I'm used to being able to efficiently query on almost anything given that it's in an index, and services like DynamoDB and AppEngine Datastore (not sure if this is what Firebase Datastore is now) always seemed to want me to build my data around their unique constraints, making it difficult to move data between platforms. That's the real benefit of SQL databases: they're (largely) compatible with one another (as long as you're not using really niche features that is).