61–70 of 101 posts
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.
They are end of lifing v1, which could go to zero. V2 can't. Are there any truly serverless SQL databases out there?
sqlite ;)
Earlier quoted context omitted.
I've never used it and it's still in beta, but I think Cloudflare D1 would qualify: https://developers.cloudflare.com/d1/
"Maximum database size 2 GB (Workers Paid) beta" (but you can have up to 50.000 databases) https://developers.cloudflare.com/d1/platform/limits/
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 ar…
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?
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?
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.
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.
Earlier quoted context omitted.
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.
(Neon CEO). It's possible and here is the recipe: https://twitter.com/nikitabase/status/1725394843285766463
Earlier quoted context omitted.
(Neon CEO). It's possible and here is the recipe: https://twitter.com/nikitabase/status/1725394843285766463
It helps but does not fully solve it if I need PG to have 512 GB of memory buffers under load to have reasonable latency starting from 0 and going through a number of VM migrations to finally get to properly sized VM with 512 GB of hot data in memory gonna cause a ton of latency.
In the future we are considering separating the buffer pool from compute and turning off compute doesn't drop the buffer cache. It's a research project but PolarDB did that for AliCloud.
(CEO of neon.tech here) 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 accomplish…
So how does your company do it?
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.