I guess a good opportunity for someone to build a good alternative. Although it's hard to get it right because if you scale to 0 people will complain about latency and if you don't it's not really serverless.
Corporate customers that runs AWS, GCP or Azure at not looking for alternative outside of their cloud providers. Most solution architecture are designed with the assumption that all your ressources will be inside the same vnet or subnet, in a given cloud provider. And I am not talking about any egress fees yet.
I think the problem is that we're trying to take paradigms that are designed to be serverful (is that a word?) and shoe-horn them into working in a serverless way.
We wanted to switch to Aurora in our company about a year ago. We tried serverless first but decided against it. We ended up using Aurora provisioned. Main reason was cost. Aurora Serverless was 20%-40% more expensive than Aurora provisioned.
One area where Aurora is superior to non-Aurora in AWS is replication lag. When running non-Aurora MySQL servers, we had replica lag sometimes reach an hour making read replicas useless. With Aurora provisioned, replica lag is always under 30ms.
If your app is database heavy and you end-up using database pretty much 24/7, don't fall for serverless hype and go with Aurora Provisioned.
Honest question, why not just use dynamodb? If I'm already mostly server less and AWS, dynamodb seems like a natural choice for a persistent store in a world where cost and zero-scaling is important.
Yeah agreed. It's about tradeoffs. If you want scale to zero with low latency DynamoDB already exists and provides that. The tradeoff is you give up all the nice features of a RDMS.
DynamoDB is _fantastic_ for certain scenarios. But, you also need to know your access patterns upfront and more or less end up hardcoding your indexes into the "table design". It's not a 1:1 replacement for a typical relational DB's use cases.
Dynamo is NoSQL, with all the architectural tradeoff that brings: Say goodbye to joins! So depending on how your data looks like, dynamo can an pretty bad fit. Do not run your reporting engine in Dynamo.
It gets worse than that though, as Dynamo's usage on large tables depends on its hottest shard, and other than setting primary keys, you have no control over how it shards. The story of people moving to dynamo and touting its advantages, just to move out a year later because the shape of their data makes dynamo prohibitively expensive as the data grows is pretty common. I once worked at a place where they stored historical data in dynamo, leading to a substandard hash key. Most of the time the db was idle, but when it wasn't, the sharding scheme made them pay a good 500x capacity than it was actually in use, because while a shard was red hot, others were completely idle. The monthly price for this relatively unimportant feature ended up being higher than the office's rent, in San Francisco.
If your table's key is UUIDs, and the chances of querying one record or another is almost perfectly flat, then sure, dynamo away! But if you walk away from it very best use case, and you suddenly start having any amount of data... dynamo can become really, really expensive. I'd not say you should never use it, but it's a really scary first place to go, precisely if you care about costs.
I am the CEO of Nile. We are serverless Postgres built explicitly for modern SaaS workloads. We do provide true serverless with no cold start time. We are able to do this because we made Postgres tenant aware. We hope to share more details on how we do it soon. https://www.thenile.dev/
Serverless V2 is also shit. The minimal one equivalent ACU to a regular instance has lots of latency spikes and much slower than a t3 instance.
We also tried serverless Redis. We have a tiny machine at %10 CPU utilization, but sustained queries. It costs 20x more. We were very afraid of the result we just ran it for an hour to get an idea.
Serverless, pay per use sounds only good if you have very few or unusual traffic.
We just run a monolithic but stateless Spring Boot Application and a dedicated RDS instance with reader in stand by. Only serverless dependency is SQS because it works nice enough. This simple infra has allowed us to iterate and pivot our startup very fast as needed. We still need more customers though.
Scaling to zero is tricky. In order to make it work you need to
1. Separate storage and compute which aurora has done
2. Have a proxy between the user and an actual VM in which you host Postgres
3. Spin up this VM after authenticating a connection, stand up Postgres inside the VM and run the query
You need to do all that very quickly- ideally in a couple hundred ms. This can only be accomplished with having a warm pool of VM or having extremely fast microVMs like firecracker.
I believe AWS aurora just uses ec2 and that’s why scale to 0 is turned off
I had settled on "scale to zero" as my chosen definition for it, because it was the only definition that truly made sense to me and that I very strongly valued.
Apparently AWS don't think it means that.
I guess it just means "you'll never have to SSH in and upgrade anything"?
The other thing that surprises me here is that one of AWS's biggest selling points is how rarely they break existing apps by turning off services developers depend on.
It typically means the unit of management (and billing) are not physical constructs (or abstractions over them). So no servers/instances/nodes etc.
You manage purely logical containers like databases and tables, the serverless service takes care of the logical to physical mapping. This lets them get better density, manage patching scaling, and a ton of other things
I still consider "serverless" to mean something that does in fact scale to zero. You also don't necessarily need to SSH in and upgrade stuff with a managed service either but RDS isn't exactly serverless even though you don't really need to service the database server yourself.
Serverless is a paradigm where you pay for capacity, not for a specific number of instances. It's extending "cattle, not pets" beyond VMs to databases.
In theory it provides better incentives for both parties:
Customers don't have to pick instance size, etc. to try and accomodate their workload. They can buy throughput, etc. in fractions of an actual instance. They can look at their quota usage to determine whether to "scale up" or "scale down".
Service providers are incentivized to optimize their software. If you sell instances + a service on top, there's a perverse incentive not to make your code too fast or people will buy fewer instances. In serverless, providers are incentivized to reduce their costs and optimize the entire stack.
Scale to zero isn't necessarily a property of serverless - a service provider can agree to keep your data on ice for free, but that's a business decision.
> I guess it just means "you'll never have to SSH in and upgrade anything"?
To me that is just "managed". I agree, serverless means scale to 0 (compute and costs). I'm so glad I left AWS Aurora Serverless after how much I disliked v1 and never considered v2. If I was still stuck on them my costs would double or more for my dev/qa environments (which I had scale to 0).
I learned the expensive wya that Aurora Serverless v2 does not, in fact, scale down to 0 when I created three instances for a few days when I was testing out configuration changes. It ended up costing us $300.
Aurora Postgres is an interesting product where AWS made significant changes to Postgres storage architecture, however it has a fairly high fixed cost.
It seems in many cases RDS Postgres is cheaper and even when using Aurora, using fixed-size instance classes instead of "serverless" autoscaling classes (with ACUs) is a lot cheaper. Fixed Aurora on-demand instances are roughly 17% the cost of ACUs. Fixed instances are usually >= 30% cheaper on top of that if you reserve.
Aurora heavily favors performance and availability over cost.
I started using the smallest VM I can that's free. On google cloud it's 1 GB RAM, 30 GB hard drive, small CPU. I run apt install -y postgresql after I create it and run my golang app and the database ON THE SAME VM! It's amazing how much you can do with that all for free.
Reminder that AWS Aurora claims to have broken the CAP theorem. The literature doesn’t clarify whether they are consistent or available, and when you ask AWS directly, they tell you the CAP theorem isn’t relevant due to the way Aurora is built.
They claim 99.99% availability or whatever the figure is, that it’s self healing, allows up to 2 replicas to be down for write availability and 3 replicas to be down for read availability. They promise “millisecond consistency”, whatever that even means.
Some of the blogs mention that they use distributed state to extract slivers of consistency across the nodes, which is just scary stuff to hear.
I’m seeing more and more usage of Aurora due to the magical component it offers, but I can’t wrap my head around what it’s actually supposed to be, and what the failure model is, like I can with RDS PG and MySQL.
AWS Serverless MySQL/Postgres offerings are straight trash. I used v1 to build a new app but had nothing but problems. Extremely slow starts (from zero), horrible scaling (it would always get stuck), (relatively) huge bills for the smallest capacity, limitations all over the place. After the first year on that I looked into v2 but my costs would have doubled and I didn't believe their promises of faster scaling. I moved to PlanetScale [0] and was very happy ($30/mo covered prod and dev/qa vs well over that for v1 even with having scale to zero on the AWS dev/qa instances). Also you can quickly be forced into paying for RDS Proxy if you are using lambdas/similar which is not cheap (for me). PS doesn't scale to 0 but at the time $30/mo was a decent savings over AWS Aurora Serverless.
This year I started to run into some issue with PS mainly around their plans changing (went from pay for reads/writes/storage to pay for compute/storage). Yes, yes, I know they still offer the $30/mo plan but it's billed as "Read/write-based billing for lower-traffic applications" and they dropped all mentions of auto-scaling. That coupled with them sleeping your non-prod DB branches (no auto-wakeup, you had to use the API or console) even after saying that was a feature of the original $30 plan rubbed me the wrong way. Eventually the costs (for what I was getting) were way too out of whack. My app is single-tenant (love it or hate it, it's what it is) so for each customer I was paying $30/mo even though this is event-based software (like in-person, physical events that happen once a year) so for most the year the DB sat there and did nothing.
Given all that I looked into Neon [1] (which I had heard of here on HN, but PS support suggested them, kudos to them for recommending a competitor, I always liked their support/staff) and while going from MySQL to Postgres wasn't painless it was way easier than I had anticipated. It was one of the few times Prisma "just worked", I don't think I'd use it again though, that DB engine is so heavy especially in a lambda. I just switched over fully last week to Neon and things seem to have gone smoothly. I can now run multiple databases on the same shared compute and it scales to 0. In fact it's scale up time is absurdly fast, the DB will "wake up" on it's own when you connect to it and unlike AWS Aurora Serverless v1 it comes up in seconds instead of 30-60+ so you don't even have to account for it. With AWS I had to have something poll the backend waiting to see if the DB was awake yet, to fire off my requests, if it was asleep. With Neon I don't even consider it, the first requests just take an extra second or two if that.
I don't have any ill will towards PlanetScale and I quite enjoyed their product for almost the whole time I used it. Also their support is very responsive and I loved the branching/merging features (I'll miss those but zero-downtime migrations aren't required for my use-case, just nice to have). In fact if I had written my app to be multi-tenant then I'd probably still be on them since I could just scale up to one of their higher plans. It does seem like Neon is significantly (for me/my workload) cheaper for more compute, I had queries taking _forever_ on PS that come back in a second or less on Neon all while paying less.
All that said, I _highly_ recommend checking out Neon if you need "serverless" hosting for Postgres that scales to 0.
[+] [-] qaq|2 years ago|reply
[+] [-] bob1029|2 years ago|reply
[+] [-] graphe|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] htrp|2 years ago|reply
[+] [-] zacksiri|2 years ago|reply
[+] [-] pandastronaut|2 years ago|reply
[+] [-] bradhe|2 years ago|reply
[+] [-] zerof1l|2 years ago|reply
One area where Aurora is superior to non-Aurora in AWS is replication lag. When running non-Aurora MySQL servers, we had replica lag sometimes reach an hour making read replicas useless. With Aurora provisioned, replica lag is always under 30ms.
If your app is database heavy and you end-up using database pretty much 24/7, don't fall for serverless hype and go with Aurora Provisioned.
[+] [-] jvanderbot|2 years ago|reply
[+] [-] wmfiv|2 years ago|reply
[+] [-] danielbarla|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] qvrjuec|2 years ago|reply
[+] [-] pid-1|2 years ago|reply
[+] [-] hibikir|2 years ago|reply
It gets worse than that though, as Dynamo's usage on large tables depends on its hottest shard, and other than setting primary keys, you have no control over how it shards. The story of people moving to dynamo and touting its advantages, just to move out a year later because the shape of their data makes dynamo prohibitively expensive as the data grows is pretty common. I once worked at a place where they stored historical data in dynamo, leading to a substandard hash key. Most of the time the db was idle, but when it wasn't, the sharding scheme made them pay a good 500x capacity than it was actually in use, because while a shard was red hot, others were completely idle. The monthly price for this relatively unimportant feature ended up being higher than the office's rent, in San Francisco.
If your table's key is UUIDs, and the chances of querying one record or another is almost perfectly flat, then sure, dynamo away! But if you walk away from it very best use case, and you suddenly start having any amount of data... dynamo can become really, really expensive. I'd not say you should never use it, but it's a really scary first place to go, precisely if you care about costs.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] donatj|2 years ago|reply
[+] [-] 1letterunixname|2 years ago|reply
[+] [-] mooreds|2 years ago|reply
Are there any truly serverless SQL databases out there?
[+] [-] infra_dev|2 years ago|reply
[+] [-] rohansingh|2 years ago|reply
[+] [-] tristan957|2 years ago|reply
https://neon.tech
[+] [-] travem|2 years ago|reply
https://www.pingcap.com/tidb-serverless/
[+] [-] dcchambers|2 years ago|reply
sqlite ;)
[+] [-] CSDude|2 years ago|reply
We also tried serverless Redis. We have a tiny machine at %10 CPU utilization, but sustained queries. It costs 20x more. We were very afraid of the result we just ran it for an hour to get an idea.
Serverless, pay per use sounds only good if you have very few or unusual traffic.
We just run a monolithic but stateless Spring Boot Application and a dedicated RDS instance with reader in stand by. Only serverless dependency is SQS because it works nice enough. This simple infra has allowed us to iterate and pivot our startup very fast as needed. We still need more customers though.
[+] [-] Buttons840|2 years ago|reply
And most of those cases can be handled by a $5 a month instance. Thus, usually, the most serverless can save you is $5 a month.
I suppose the real appeal of serveless is you don't have to worry about maintaining the server, doing updates, etc.
[+] [-] RhodesianHunter|2 years ago|reply
[+] [-] nikita|2 years ago|reply
Scaling to zero is tricky. In order to make it work you need to
1. Separate storage and compute which aurora has done
2. Have a proxy between the user and an actual VM in which you host Postgres
3. Spin up this VM after authenticating a connection, stand up Postgres inside the VM and run the query
You need to do all that very quickly- ideally in a couple hundred ms. This can only be accomplished with having a warm pool of VM or having extremely fast microVMs like firecracker.
I believe AWS aurora just uses ec2 and that’s why scale to 0 is turned off
[+] [-] mkesper|2 years ago|reply
[+] [-] htrp|2 years ago|reply
[+] [-] simonw|2 years ago|reply
I had settled on "scale to zero" as my chosen definition for it, because it was the only definition that truly made sense to me and that I very strongly valued.
Apparently AWS don't think it means that.
I guess it just means "you'll never have to SSH in and upgrade anything"?
The other thing that surprises me here is that one of AWS's biggest selling points is how rarely they break existing apps by turning off services developers depend on.
[+] [-] wnolens|2 years ago|reply
You manage purely logical containers like databases and tables, the serverless service takes care of the logical to physical mapping. This lets them get better density, manage patching scaling, and a ton of other things
[+] [-] Hamuko|2 years ago|reply
[+] [-] jamessb|2 years ago|reply
https://dl.acm.org/doi/pdf/10.1145/3587249 (pdf)
[+] [-] marcosdumay|2 years ago|reply
We have "managed" for that.
But if you manage to get a meaning for "serverless", I would love to know it too.
[+] [-] throwboatyface|2 years ago|reply
In theory it provides better incentives for both parties:
Customers don't have to pick instance size, etc. to try and accomodate their workload. They can buy throughput, etc. in fractions of an actual instance. They can look at their quota usage to determine whether to "scale up" or "scale down".
Service providers are incentivized to optimize their software. If you sell instances + a service on top, there's a perverse incentive not to make your code too fast or people will buy fewer instances. In serverless, providers are incentivized to reduce their costs and optimize the entire stack.
Scale to zero isn't necessarily a property of serverless - a service provider can agree to keep your data on ice for free, but that's a business decision.
[+] [-] joshstrange|2 years ago|reply
To me that is just "managed". I agree, serverless means scale to 0 (compute and costs). I'm so glad I left AWS Aurora Serverless after how much I disliked v1 and never considered v2. If I was still stuck on them my costs would double or more for my dev/qa environments (which I had scale to 0).
[+] [-] superdeeda|2 years ago|reply
[+] [-] nijave|2 years ago|reply
It seems in many cases RDS Postgres is cheaper and even when using Aurora, using fixed-size instance classes instead of "serverless" autoscaling classes (with ACUs) is a lot cheaper. Fixed Aurora on-demand instances are roughly 17% the cost of ACUs. Fixed instances are usually >= 30% cheaper on top of that if you reserve.
Aurora heavily favors performance and availability over cost.
[+] [-] nforgerit|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] lijok|2 years ago|reply
[+] [-] JackFr|2 years ago|reply
[+] [-] andrewfromx|2 years ago|reply
[+] [-] dcchambers|2 years ago|reply
[+] [-] slau|2 years ago|reply
They claim 99.99% availability or whatever the figure is, that it’s self healing, allows up to 2 replicas to be down for write availability and 3 replicas to be down for read availability. They promise “millisecond consistency”, whatever that even means.
Some of the blogs mention that they use distributed state to extract slivers of consistency across the nodes, which is just scary stuff to hear.
I’m seeing more and more usage of Aurora due to the magical component it offers, but I can’t wrap my head around what it’s actually supposed to be, and what the failure model is, like I can with RDS PG and MySQL.
[+] [-] joshstrange|2 years ago|reply
This year I started to run into some issue with PS mainly around their plans changing (went from pay for reads/writes/storage to pay for compute/storage). Yes, yes, I know they still offer the $30/mo plan but it's billed as "Read/write-based billing for lower-traffic applications" and they dropped all mentions of auto-scaling. That coupled with them sleeping your non-prod DB branches (no auto-wakeup, you had to use the API or console) even after saying that was a feature of the original $30 plan rubbed me the wrong way. Eventually the costs (for what I was getting) were way too out of whack. My app is single-tenant (love it or hate it, it's what it is) so for each customer I was paying $30/mo even though this is event-based software (like in-person, physical events that happen once a year) so for most the year the DB sat there and did nothing.
Given all that I looked into Neon [1] (which I had heard of here on HN, but PS support suggested them, kudos to them for recommending a competitor, I always liked their support/staff) and while going from MySQL to Postgres wasn't painless it was way easier than I had anticipated. It was one of the few times Prisma "just worked", I don't think I'd use it again though, that DB engine is so heavy especially in a lambda. I just switched over fully last week to Neon and things seem to have gone smoothly. I can now run multiple databases on the same shared compute and it scales to 0. In fact it's scale up time is absurdly fast, the DB will "wake up" on it's own when you connect to it and unlike AWS Aurora Serverless v1 it comes up in seconds instead of 30-60+ so you don't even have to account for it. With AWS I had to have something poll the backend waiting to see if the DB was awake yet, to fire off my requests, if it was asleep. With Neon I don't even consider it, the first requests just take an extra second or two if that.
I don't have any ill will towards PlanetScale and I quite enjoyed their product for almost the whole time I used it. Also their support is very responsive and I loved the branching/merging features (I'll miss those but zero-downtime migrations aren't required for my use-case, just nice to have). In fact if I had written my app to be multi-tenant then I'd probably still be on them since I could just scale up to one of their higher plans. It does seem like Neon is significantly (for me/my workload) cheaper for more compute, I had queries taking _forever_ on PS that come back in a second or less on Neon all while paying less.
All that said, I _highly_ recommend checking out Neon if you need "serverless" hosting for Postgres that scales to 0.
[0] https://planetscale.com/
[1] https://neon.tech/