TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

AWS cancels serverless Postgres service that scales to zero

118 点作者 goeldhru超过 1 年前

17 条评论

qaq超过 1 年前
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.
评论 #38939814 未加载
评论 #38939477 未加载
评论 #38939571 未加载
评论 #38939533 未加载
评论 #38939512 未加载
评论 #38939716 未加载
评论 #38939500 未加载
zerof1l超过 1 年前
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.<p>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.<p>If your app is database heavy and you end-up using database pretty much 24&#x2F;7, don&#x27;t fall for serverless hype and go with Aurora Provisioned.
jvanderbot超过 1 年前
Honest question, why not just use dynamodb? If I&#x27;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.
评论 #38939445 未加载
评论 #38939584 未加载
评论 #38953545 未加载
评论 #38939318 未加载
评论 #38939592 未加载
评论 #38939753 未加载
donatj超过 1 年前
The title includes Postgres, but if I’m understanding correctly it’s actually both flavors of Aurora - Postgres and MySQL
1letterunixname超过 1 年前
<i>Ignore requirements of paying customers because product guy or developer guy knows best.</i> - The Amazon Way(tm)
mooreds超过 1 年前
They are end of lifing v1, which could go to zero. V2 can&#x27;t.<p>Are there any truly serverless SQL databases out there?
评论 #38943601 未加载
评论 #38939342 未加载
评论 #38940216 未加载
评论 #38939502 未加载
评论 #38939731 未加载
CSDude超过 1 年前
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.<p>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.<p>Serverless, pay per use sounds only good if you have very few or unusual traffic.<p>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.
评论 #38939593 未加载
评论 #38939580 未加载
nikita超过 1 年前
(CEO of neon.tech here)<p>Scaling to zero is tricky. In order to make it work you need to<p>1. Separate storage and compute which aurora has done<p>2. Have a proxy between the user and an actual VM in which you host Postgres<p>3. Spin up this VM after authenticating a connection, stand up Postgres inside the VM and run the query<p>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.<p>I believe AWS aurora just uses ec2 and that’s why scale to 0 is turned off
评论 #38939688 未加载
评论 #38939544 未加载
simonw超过 1 年前
The term &quot;serverless&quot; is so confusing if to me.<p>I had settled on &quot;scale to zero&quot; as my chosen definition for it, because it was the only definition that truly made sense to me and that I very strongly valued.<p>Apparently AWS don&#x27;t think it means that.<p>I guess it just means &quot;you&#x27;ll never have to SSH in and upgrade anything&quot;?<p>The other thing that surprises me here is that one of AWS&#x27;s biggest selling points is how rarely they break existing apps by turning off services developers depend on.
评论 #38939351 未加载
评论 #38939332 未加载
评论 #38939528 未加载
评论 #38939934 未加载
评论 #38939292 未加载
评论 #38939457 未加载
superdeeda超过 1 年前
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.
评论 #38939132 未加载
评论 #38939431 未加载
nijave超过 1 年前
Aurora Postgres is an interesting product where AWS made significant changes to Postgres storage architecture, however it has a fairly high fixed cost.<p>It seems in many cases RDS Postgres is cheaper and even when using Aurora, using fixed-size instance classes instead of &quot;serverless&quot; autoscaling classes (with ACUs) is a lot cheaper. Fixed Aurora on-demand instances are roughly 17% the cost of ACUs. Fixed instances are usually &gt;= 30% cheaper on top of that if you reserve.<p>Aurora heavily favors performance and availability over cost.
评论 #38939546 未加载
评论 #38939331 未加载
nforgerit超过 1 年前
So if I understand correctly, we&#x27;re (economically) back at the classic model of continuously running a db in a process, right?
评论 #38939450 未加载
评论 #38939680 未加载
JackFr超过 1 年前
I think the big takeaway is that scale-to-zero customers aren&#x27;t where they&#x27;re making their money.
评论 #38939671 未加载
andrewfromx超过 1 年前
I started using the smallest VM I can that&#x27;s free. On google cloud it&#x27;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&#x27;s amazing how much you can do with that all for free.
评论 #38939722 未加载
评论 #38939697 未加载
dcchambers超过 1 年前
I have a feeling most people chasing &quot;serverless&quot; postgres or mysql with the ability to scale to zero are perfect candidates for sqlite.
slau超过 1 年前
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.<p>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.<p>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.<p>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.
评论 #38939609 未加载
评论 #38939569 未加载
评论 #38939699 未加载
评论 #38939375 未加载
评论 #38939357 未加载
joshstrange超过 1 年前
AWS Serverless MySQL&#x2F;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&#x27;t believe their promises of faster scaling. I moved to PlanetScale [0] and was very happy ($30&#x2F;mo covered prod and dev&#x2F;qa vs well over that for v1 even with having scale to zero on the AWS dev&#x2F;qa instances). Also you can quickly be forced into paying for RDS Proxy if you are using lambdas&#x2F;similar which is not cheap (for me). PS doesn&#x27;t scale to 0 but at the time $30&#x2F;mo was a decent savings over AWS Aurora Serverless.<p>This year I started to run into some issue with PS mainly around their plans changing (went from pay for reads&#x2F;writes&#x2F;storage to pay for compute&#x2F;storage). Yes, yes, I know they still offer the $30&#x2F;mo plan but it&#x27;s billed as &quot;Read&#x2F;write-based billing for lower-traffic applications&quot; 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&#x27;s what it is) so for each customer I was paying $30&#x2F;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.<p>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&#x2F;staff) and while going from MySQL to Postgres wasn&#x27;t painless it was way easier than I had anticipated. It was one of the few times Prisma &quot;just worked&quot;, I don&#x27;t think I&#x27;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&#x27;s scale up time is absurdly fast, the DB will &quot;wake up&quot; on it&#x27;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&#x27;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&#x27;t even consider it, the first requests just take an extra second or two if that.<p>I don&#x27;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&#x2F;merging features (I&#x27;ll miss those but zero-downtime migrations aren&#x27;t required for my use-case, just nice to have). In fact if I had written my app to be multi-tenant then I&#x27;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&#x2F;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.<p>All that said, I _highly_ recommend checking out Neon if you need &quot;serverless&quot; hosting for Postgres that scales to 0.<p>[0] <a href="https:&#x2F;&#x2F;planetscale.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;planetscale.com&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;neon.tech&#x2F;" rel="nofollow">https:&#x2F;&#x2F;neon.tech&#x2F;</a>