Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS cancels serverless Postgres service that scales to zero

datanami.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: AWS cancels serverless Postgres service that scales to zero

#91

Post by zer00eyz »

4ggr0 wrote: post #64
zer00eyz wrote: post #36

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?

To answer, daily peak, 3pm PT to about 11pm PT...

That starts 6pm ET, so post work and kids, it's "free time". By 6pm PT(9pm ET) we would be hitting a peak, for the next hour or two and then winding down till 11. It's the prime time for "adult working women" as a demographic.

Re: AWS cancels serverless Postgres service that scales to zero

#92

Post by andrenotgiant »

bob1029 wrote: post #70
qaq wrote: 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.

SQL Server on Azure has an auto pause feature. All of our QA and dev instances use this. Seems to work reasonably well for us.

Do they auto-wake when you query them? How long does auto-wake take?

Re: AWS cancels serverless Postgres service that scales to zero

#93

Post by infra_dev »

mooreds wrote: post #7

They are end of lifing v1, which could go to zero. V2 can't. Are there any truly serverless SQL databases out there?

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/

Re: AWS cancels serverless Postgres service that scales to zero

#94

Post by bob1029 »

andrenotgiant wrote: post #92
bob1029 wrote: post #70

Earlier quoted context omitted.

SQL Server on Azure has an auto pause feature. All of our QA and dev instances use this. Seems to work reasonably well for us.

Do they auto-wake when you query them? How long does auto-wake take?

Yes - takes about 10-30 seconds in my experience.

Re: AWS cancels serverless Postgres service that scales to zero

#95

Post by belter »

Ao7bei3s wrote: post #89
belter wrote: post #49

Earlier quoted context omitted.

Almost any SQL workload you can move to DynamoDB

DynamoDB can't even represent SELECT * FROM items LIMIT 25 OFFSET 100. It's just not designed for that. It's not meant to be a relational DB replacement. How would you do it? Assume we want proper pagination, and not rewrite the app for cursor based "Load more" style pagination. Why? Because the React Admin provider API insists. https://github.com/marmelab/react-admin/issues/1510

Your example itself shows why you would not want to do this. The database still has to read through all the rows up to the OFFSET point...

You are not supposed to do the same query patterns. My argument is that you can substitute your relational database, by changing the app and the layout of the data to match the proper patterns for DynamoDB.

"Migrating to DynamoDB from a relational database" - https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

""How to model one-to-many relationships in DynamoDB" - https://www.alexdebrie.com/posts/dynamodb-one-to-many/

Re: AWS cancels serverless Postgres service that scales to zero

#96

Post by [deleted] »

belter wrote: post #95
Ao7bei3s wrote: post #89

Earlier quoted context omitted.

DynamoDB can't even represent SELECT * FROM items LIMIT 25 OFFSET 100. It's just not designed for that. It's not meant to be a relational DB replacement. How would you do it? Assume we want proper pagination, and not rewrite the app for cursor based "Load more" style pagination. Why? Because the React Admin provider API insists. https://github.com/marmelab/react-admin/issues/1510

Your example itself shows why you would not want to do this. The database still has to read through all the rows up to the OFFSET point... You are not supposed to do the same query patterns. My argument is that you can substitute your relational database, by changing the app and the layout of the data to match the proper patterns for DynamoDB. "Migrating to DynamoDB from a relational database" - https://docs.aws.amaz…

[deleted]

Re: AWS cancels serverless Postgres service that scales to zero

#97

Post by 4ggr0 »

zer00eyz wrote: post #91
4ggr0 wrote: post #64

Earlier quoted context omitted.

> [...] 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?

To answer, daily peak, 3pm PT to about 11pm PT... That starts 6pm ET, so post work and kids, it's "free time". By 6pm PT(9pm ET) we would be hitting a peak, for the next hour or two and then winding down till 11. It's the prime time for "adult working women" as a demographic.

Ah I see. So it's just generally the "adult working parent" prime time, but you had a focus on women because they were the service's target demographic.

Re: AWS cancels serverless Postgres service that scales to zero

#99

Post by earthling8118 »

Ao7bei3s wrote: post #89
belter wrote: post #49

Earlier quoted context omitted.

Almost any SQL workload you can move to DynamoDB

DynamoDB can't even represent SELECT * FROM items LIMIT 25 OFFSET 100. It's just not designed for that. It's not meant to be a relational DB replacement. How would you do it? Assume we want proper pagination, and not rewrite the app for cursor based "Load more" style pagination. Why? Because the React Admin provider API insists. https://github.com/marmelab/react-admin/issues/1510

If you place arbitrary restrictions upon it then of course it won't fit your model. Dynamo can handle pagination easily by passing in the last seen ID in the request. We used IDs that were lexigraphically sortable by time which has some nice properties such as never losing your position due to extra items being inserted in the middle of your query. Offset/limit aren't fun to work with.

You can go further by using the streams feature to dump your data into an analytical database for your querying needs.

Re: AWS cancels serverless Postgres service that scales to zero

#100

Post by yencabulator »

zacksiri wrote: post #32
qaq wrote: 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

Neon is only scale-to-zero from the point of view of the tenants; whoever runs the software, must keep nodes running, including triple-replicated WAL storage.
Post reply on HN