21–30 of 125 posts
This makes sense, but also not surprised. In today's world there are countless Postgres providers (Supabase, RDS, DigitalOcean, GCP, Azure, etc) so there is plenty of choice now. Although I don't see why anyone would choose niche providers today other than the cloud provided ones like RDS now.
This makes sense, but also not surprised. In today's world there are countless Postgres providers (Supabase, RDS, DigitalOcean, GCP, Azure, etc) so there is plenty of choice now. Although I don't see why anyone would choose niche providers today other than the cloud provided ones like RDS now.
How does one handle a zero downtime migration in this case? On a database of 50gib+ is this a solved problem in Postgres world?
Isn't this just the typical case of changing DB hosts? You set up replication to new location and migrate apps to new location?
How does one handle a zero downtime migration in this case? On a database of 50gib+ is this a solved problem in Postgres world?
https://gds.blog.gov.uk/2024/01/17/how-we-migrated-our-postg...
With their approach, there would always be a minimum of 1 second downtime from the DNS changeover.
Earlier quoted context omitted.
Because RDS forces you to deal with the AWS behemouth instead if just changing your database connect parameters.
I would argue there is limited/no market for Database as a Service where the database isn’t hosted on the same cloud provider and region as your application. Egress costs way too much for that. So you’d assume most people are already dealing with the AWS behemoth. And if the cloud provider is providing a competing Database as a Service then it’s almost impossible to compete.
What a shame. This is "cloud" as it ought to be: be clear about the service you provide, provide it well, no lock in. Simple and matter-of-factly. I just started evaluating them about a month ago, loved their hosted postgres and a couple of days later the EOL announcement poped up in my dashboard :(
People get dragged into the big cloud when they start using one service or the other, moving the database if for no other reason than to minimize latency seems smart.
I do agree with other people on here that dealing with a laser focused independent company is far preferable than big cluod.
This makes sense, but also not surprised. In today's world there are countless Postgres providers (Supabase, RDS, DigitalOcean, GCP, Azure, etc) so there is plenty of choice now. Although I don't see why anyone would choose niche providers today other than the cloud provided ones like RDS now.
Supabase provides a lot of added value regarding tools and auth with SSO, so it’s more than just Postgres.
Any strong alternatives?
There's quite a few places around. Also Ubicloud look interesting, though I've not personally used them: https://www.ubicloud.com/use-cases/postgresql
I'd be happy to answer if anyone has any questions about our managed service.
What a shame. This is "cloud" as it ought to be: be clear about the service you provide, provide it well, no lock in. Simple and matter-of-factly. I just started evaluating them about a month ago, loved their hosted postgres and a couple of days later the EOL announcement poped up in my dashboard :(
Absolutely. I’ve been a customer for many years and it’s always been a pleasure to interact with such a simple, transparent and “to the point” UI. The fact that they are a tiny team also bumps it up the list for me.