Live data from Hacker News

AWS cancels serverless Postgres service that scales to zero

datanami.com

71–80 of 101 posts

Re: AWS cancels serverless Postgres service that scales to zero

#71
post #49
post #11

Earlier quoted context omitted.

Because you need SQL. Dynamo can be quite powerful for querying if you use all of its features but it won't be as flexible as just using SQL

Almost any SQL workload you can move to DynamoDB

https://aws.amazon.com/blogs/database/how-to-determine-if-am...

> Some unsuitable workloads for DynamoDB include:

> Services that require ad hoc query access. Though it’s possible to use external relational frameworks to implement entity relationships across DynamoDB tables, these are generally cumbersome.

> Online analytical processing (OLAP)/data warehouse implementations. These types of applications generally require distribution and the joining of fact and dimension tables that inherently provide a normalized (relational) view of your data.

> Binary large object (BLOB) storage. DynamoDB can store binary items up to 400 KB, but DynamoDB is not generally suited to storing documents or images. A better architectural pattern for this implementation is to store pointers to Amazon S3 objects in a DynamoDB table.

Re: AWS cancels serverless Postgres service that scales to zero

#72
post #5

The term "serverless" is so confusing if to me. 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 rarel…

> "you'll never have to SSH in and upgrade anything"

We have "managed" for that.

But if you manage to get a meaning for "serverless", I would love to know it too.

Re: AWS cancels serverless Postgres service that scales to zero

#73
post #5

The term "serverless" is so confusing if to me. 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 rarel…

> "you'll never have to SSH in and upgrade anything" We have "managed" for that. But if you manage to get a meaning for "serverless", I would love to know it too.

"Serverless": We don't bill you if you forget to turn it off.

Re: AWS cancels serverless Postgres service that scales to zero

#74
post #10

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.

There is a good alternative, https://neon.tech check them out. Really good bunch. Product is great and it's open-sourced https://github.com/neondatabase/neon

I'll note that the storage engine is open-source as well as any Postgres modifications, but our control plane is closed-source. I work at Neon.

Re: AWS cancels serverless Postgres service that scales to zero

#76
post #61

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.

Obviously cloud computing has done wonders for building gigascale infrastructure, but it's so incredibly useful for building microscale too. You can't run half a CPU at home.

Of course you can run half a CPU at home. With Ubuntu LXD, you can easily run actual, hardware 50% cpu time, or .5 priority container. Why wouldn't you be able to have complete control over what "microscale" tasks you run on your own hardware, and own OS, that you control?

On the contrary, vCPU a completely cloud-centric product oriented concept, intended to abstract away what CPU you're actually running on, and how fast. These abstracts make orchestration and availability easier, but I think the key is a stable, public internet access. If you get a static IP, I don't see what wonders this does for "microscale". In fact, you probably have 90% unused "microcapacity" on all the personal hardware that's often idling, that is a lot less micro than any cloud provider will give you for free.

Re: AWS cancels serverless Postgres service that scales to zero

#77
post #64

Earlier quoted context omitted.

I used to work for a business that was predominantly used by women. Like clock work, at 3pm PS most weekdays there was a spike in traffic as our customers became active on our system. I would love to see the real numbers behind the costs. Is time of day dependency the real price driver here? Are some customers getting more value than others out of this system?

> [...] predominantly used by women [...] Like clock work, at 3pm PS most weekdays there was a spike in traffic what knowledge gap do i have about the collective womanhood that I don't understand why a service which is predominantly used by women gets traffic spikes at a specific time of day? Is 3PM PST when most women sync their in-built RTC?

3PM is around when school ends for most k-12 schools; if its something someone might check quickly in a free moment at/after work and/or in the car waiting to pickup kids, I can see a big spike from teachers (disproportionately women) and primary child-raisers (disproportionately women) around 3pm.

Re: AWS cancels serverless Postgres service that scales to zero

#78

Earlier quoted context omitted.

> "you'll never have to SSH in and upgrade anything" We have "managed" for that. But if you manage to get a meaning for "serverless", I would love to know it too.

"Serverless": We don't bill you if you forget to turn it off.

That's a synonym for the GP's "it scales into 0", that is evidently a bad meaning to attach to the word.

Somebody answered the GP with "it's SaaS, not IaaS". The more I think about it, the more I think this actually represent what people mean when they say it.

Re: AWS cancels serverless Postgres service that scales to zero

#79
post #49
post #11

Earlier quoted context omitted.

Because you need SQL. Dynamo can be quite powerful for querying if you use all of its features but it won't be as flexible as just using SQL

Almost any SQL workload you can move to DynamoDB

DynamoDB lacks consistency (in the ACID sense, it has been it in the CAP sense which is more related to Atomicity in ACID), so you can move an SQL workload to DynamoDB by moving the consistency parts out of the DB into the code of any application that hits the DB.

Re: AWS cancels serverless Postgres service that scales to zero

#80
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.

Post reply on HN