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.
well, they shut this down probably because they cannot afford to keep a product that bring little revenue. I never heard of AWS retiring a product (I am excluding ancient stuff like VPC classic and SimpleDB, both had an upgrade path to something superior)
AWS is Big Tech. It locks you in, and it's not easy to guard your users' privacy against them. Smaller providers (and also local in the case of 84codes) are preferred.
> and it's not easy to guard your users' privacy against them
Source?
> Smaller providers (and also local in the case of 84codes) are preferred
AWS have a reputation and stability to keep because half of the internet, governments, banks, etc. rely on them. If a small provider makes a mistake, or goes bankrupt due to unforseen circumstances, you're left holding the bag on your own.
You're being polite asking for a source. The source will, as it always does, turn out to be "some random stuff I read on the internet don't know where but everybody knows this is true".
Whit AWS you probably have to hire a decent engineer who knows how to build stuff the right way (never touch the dashboards, do all through well-tested, declarative, repeatable IaaC, set up proper replication and backups, preemptively simulating the outages, and so on).
But unless you need a complex control plane or highly dynamic scaling on a daily basis you also can do exact same thing with any non-cloud provider (and a CDN). Order some bare metal, roll out, enjoy - if it goes bad, order bare metal from someone else, redeploy to it, restore from backups, and recover in about the same time (half a day) it takes AWS to fix us-east-1 when it fails. It also probably will save a lot of money (NATgw bills alone) in the long term.
If AWS goes down, and it does, you're still left holding the bag, because no one customer is important enough for them to actually support. You can leave sad voicemails for your customer account representative, and pretty much nothing else.
The idea of AWS as some kind of bag-holding partner is risible. They're a machine that helps convert capex to opex. Any systems services they may offer along the way are purely secondary.
The post from 84codes clearly states a different motivation. If they want to focus their efforts elsewhere, that’s their decision. One doesn’t need to be “the provider” to count as success. It’s the whole point of staying small to mid-sized.
SimpleDB disappeared off the marketing pages - but I don't think it got shut down in reality until 2020 maybe? It was easily 5+ years after DynamoDB came along. There was definitely a period where there was little SimpleDB availability publicly but on the backend it kept working.
Would love it if someone had more of the detailed history.
SimpleDB still works for my company's AWS account. There's been no announcement of a shutdown that I've seen (and I check occasionally since it's almost entirely disappeared from most of AWS's documentation).
I assume AWS fully automates their stuff so the maintenance is ~0 outside their normal datacenter and SRE stuff which amortizes the total cost to ~0, so why retire a service? Just stop development.
There’s no such thing as zero cost to development teams. Who patches the security vulnerabilities? Who answers esoteric customer questions for customers with premium support contracts?
Fully agree with this sentiment it's very much our focus and goal at Crunchy Data with one big thing I'd add-great support.
I recall seeing them crop up in the early days of building and running Heroku Postgres, they were a very very early managed service provider. To my knowledge they never seemed to grow to massive scale but were a steady business (though I don't know any of the details for sure). That they were still around for over a decade is a testament from a lot of others.
I switched to DigitalOcean and it's been a delight. $15/month for a managed Postgres is a good deal, and I am really tired of the hellscape that has become AWS configuration even for the most simplest things. Isn't the whole point of the cloud is simplicity?
>Isn't the whole point of the cloud is simplicity?
Maybe for a few cloud offerings, but not for cloud in general. I think the point of the cloud is that businesses can exchange employees for services, and shift some of the maintenance responsibility.
No service is for the people who actually interact with it. It's for the ones that pay for it.
No, for example, I couldn’t manage a database as well as RDS and I wouldn’t want to, I don’t believe I could hire the several people required to replicate what RDS can do as well as RDS can do it.
The primary benefit of cloud though is that you don’t have to fight for or wait for capital expenditure budgets to grow, you don’t have to wait for hardware to arrive, you don’t have to negotiate with vendors, you don’t have to fight about how long you should keep old hardware or replace it, you don’t have to deal at all with the political or business aspects of managing millions of dollars of hardware.
I can just go on a website and click a few buttons and have something new, and the biggest argument about it is a yearly cloud budget discussion.
I completely agree. I see this point in cloud too, and this is really missing from my original comment. Cloud is a huge enabler, and basically 0 upfront cost.
The point of cloud was selling businesses on IT as a subscription. And it did start simple as "look ma, no hands managing a database".
But then biggesr cloud providers went and threw themselves heavily at sales to enterprises. And well, they start adding more features for enterprises. And as they add more features, they all more technical and security complex.
Next thing you know, you fired your on premise IT staff and hired just as many if not more staff just to babysit your aws usage. Lol
Or you subscribe to another saas service to try and automate away automating in AWS. Lol
For kitchen table startups that nevertheless deal in important data, having reliable managed PostgreSQL for much lower cost than AWS RDS would be awesome.
The main thing I'm looking for in managed PostgreSQL isn't "installation" -- that's easy -- what I need is not to have to spend weeks of configuring and testing and drilling, to be reasonably confident that I won't lose customer data.
I see DigitalOcean does PG standby servers, and daily backups, but I'm unclear on whether they're doing separate, say, WAL-based backups.
The couple mentions I saw of "PITR" seemed to conflate that with the daily backups.
> In the Create a new cluster from a backup window that opens, choose whether you want to restore to the latest transaction available or choose a point in time,
What's the "latest transaction available"?
(Is it to moments before someone ripped the cables out of the storage server? Or is it the most recent daily backup, which might've been 23 hours ago?)
> By default, the name is the original databases’ name appended with the date of the backup and the word “backup”, like originalname-aug-13-backup.
I don't want to be trying urgently to recover the businesses of myself and my customers, and find myself asking design questions akin to "Why isn't this a UTC ISO date/timestamp?" but more like "Why are the backups done in such a way that they can't be restored for this ordinary failure scenario that just happened?"
I don't see any technical reason that a cloud provider can't give enterprise DBA confidence at kitchen table startup rates, but I'd feel silly for assuming that they do.
FYI to answer your questions both Aiven (the one mentioned by ElephantSQL as the partnered migration path) and Digitalocean do regular WAL-based backups in addition to the daily, so latest transaction available is 'moments before someone ripped the cables'. It does kind of suck the docs are not super clear about that though.
Thank you. That helps. Though, not finding documentation that they even do it doesn't give me the confidence that they've been really rigorous about implementing it.
I think, the next time I need this for a kitchen table startup, I'll have see whether the documentation is much more reassuring then, or contact them.
If I need more reassurance than I'm getting, I might have to get AWS startup credits, and hope AWS costs don't outpace my ability to pay.
> Digitalocean do regular WAL-based backups in addition to the daily, so latest transaction available is 'moments before someone ripped the cables'. It does kind of suck the docs are not super clear about that though.
how do you know they do WAL backup if they don't mention it anywhere in the doc?..
Networking was drop dead simple. Basically I think all my instances got an 10.x.x.x IP address. You had a basic firewall (security groups nowadays) but that was it.
Let's say you had another account for a separate project or a client with another account.
You could literally connect to their instance via private IP.
All your own resources and all theirs were in this same 10.x.x.x address space which seemed to be globally reachable inside AWS.
The layers of config to go across account now between different orgs is wild by comparison.
The number of instance types alone for RDS is ... around 200? Then there's storage types, IOPS, multi-zone, etc. All of that without any price estimate. Which is by design, of course.
Digital Ocean will give you the cost as you configure the options. Complete transparency. This is how it SHOULD be.
Cost obfuscation is an AWS feature. I was afraid to spin up the smallest instance because I didn't want to find out it was going to cost me over $100 at the end of the billing cycle.
Given how many different companies now offering hosted Postgres it must be a challenging market to compete in.
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.
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.
Egress costs are only expensive if you're paying the artificially high mega cloud corp's inflated pricing. I've yet to pay for bandwidth for any servers on Hetzner or for Cloudflare's services.
> Because RDS forces you to deal with the AWS behemouth instead if just changing your database connect parameters.
This is one of the things I quite liked about Azure, funnily enough. They basically give you a connection string. It's not ideal, and I think for production we did something slightly different with Azure identities, but it got us going quickly, and the identities thing devops just swapped in later behind the scenes. Other than that it was just regular Postgres.
Not OP but even setting up an AWS Account is a roughly hundred step process. Root account, IAM Accounts, I just tried using CLIv2 which asked me to set up something called Identity center first? Billing is complicated, setting up looking and metrics... Another two services. Some other best practice things... Also extra services.
AWS is complicated.
There is - for me and seemingly others - a lot of value in avoiding this complexity.
AWS used to be easy to use for "drive by users".
It's not anymore.
If you are using AWS anyway and are accustomed to it, obviously, RDS is a good choice. But I don't want to learn what DNS and Filesystem are called in AWS-speak just to shoehorn myself into getting stuck with AWS forever, when all I need is a hosted database so I don't have to worry about backups, etc.
My typical situation sees small to medium (virtual) servers that run software for tens to possibly thousands of users. There are plenty of use cases that aren't "google scale" and can be operated on a simple machine and can profit from a "simple" hosted DB.
Rant: Same goes for things like CDNs, I'd guess that 99% of websites don't get nearly the amount of traffic that a simple linux server couldn't handle out of the box. Let alone need sub 100ms ping responses, yet there is this weird cargo cult that requires putting your terraformed, docker stuff running javascript from with a python container with multiple layers of caching behind cloudflare because people don't dare consider simple architectures.
one way to think: managing state (database) is hard. You need to manage replication, backups, version upgrades etc.
Compared to this, stateless application server part is usually quite easy. If you would like to be cost effective, with small team, you could outsource the database part and manage the applications on dedicated servers.
It's more expensive than AWS RDS and Google Cloud SQL, but their service seems more comprehensive, with fast major version upgrade, multi-cloud deployment and built-in PgBouncer integration. For business critical operations, it is probably worth it.
We've been a customer for long for some of out applications. It's a shame but I get their reasoning. The hosted postgresql market is getting crowded and it is difficult for a small shop to stand out.
I'm wondering why are they completely cutting off their hosted DB services instead of scaling it down. Is this something that's so time-consuming to provide at scale?
I'm also questioning their decision to put all their chips on message brokers. Don't those services require fast and reliable access that is only possible if they are provided as support services running within the same network? They seem to be the kind of service that only makes sense as a value-added service provided as part of a more general cloud hosting offering.
> Is this something that's so time-consuming to provide at scale?
I suspect it's not time but money—they host the service on various cloud providers in various data centers so that latency is low. In order to pull that off economically they have to be doing some tricks that are only possible at scale, and if they're seeing a lot of natural attrition those techniques will stop working, and they'll probably end up footing an AWS/GCP/Azure bill that won't leave any margin left for the other expenses.
That's what I though, focusing on message-broker as-a-service sounds bonkers. I assume there must be a business case there that is not obvious unless you are on the inside.
4. redeploy your service. Usually, deployments are hot swapped so you continue ingesting into your old database, replicating to the new one, until the deployment is complete. If you use sequential identifiers, I don't think it's possible to do this without dropping a few records due to duplication, unfortunately. If duplication is something you cannot handle, you should deploy two instances of your application in parallel, take the original instance down, wait for replication to complete, and then switch to the new one. This will probably be <10s downtime.
I did something similar recently, but I switched both application hosts and database providers. End user DNS replication would theoretically take some time, but for me consumption dropped to zero within a minute or so https://shottr.cc/s/1ngg/SCR-20240407-hoa.png
From what the migration doc says, it will only support pgdump migration. Meaning it will require downtime, or at least write downtime.
Create backup using pgdump, restore the dump to new database. While making sure no changes to the old db before switch over.
The ability to replicate from a database service is an extremely important consideration when picking any DBaaS. If you cannot do a no-downtime migration out of a database provider, you are needlessly locking yourself into a vendor.
Ouch that will make migrating anything over a few hundred gigs almost impossible. Our postgres db is about 2TB and pgdump stopped being viable a long time ago.
you can use pg_basebackup to kickstart a replication slave. You can then just just down old and use new with ~1sec downtime. If you need to upgrade postgres at same time, you can then cascade to another one slave on same "new" host for safety, and pg_upgrade on that one. This will result in a bit more downtime, but also upgrading postgres version.
2025-01-28
Brownout
Read more about the Brownout schedule below.
2025-02-28
Blackout
Service terminated. All data deleted.
Brownout schedule
First week
1 hour down each day
Second/Third week
8 hours down each day
Forth week
24h down each day
So, in case you haven't migrated off with a month to go before full shutdown (possibly because you haven't realised you're using the service, etc), they introduce intentional outages of increasing length. Harsh but effective!
What's the deal with the fourth week? The service is down, but data is not yet deleted - is there still a way to export your data at that point?
Hetzner unfortunately only offers VMs in US, not bare metal servers. We are evaluating potential providers. LeaseWeb is one strong candidate right now.
If Hetzner offers bare metal servers in the future, we would definitely prefer them as well since we are already using Hetzner in EU. However, at the end, the goal is being provider agnostic as much as possible.
Are you planning on offering a hosted ClickHouse service? After all, for analytical use cases latency doesn't matter so much, hence it would make sense even for companies in other continents to use your service.
Few potential users also asked about ClickHouse. We might offer it at some point, but for the sake of full transparency, it is not on our roadmap right now. There are bunch of other essential services we need to offer first, like K8s.
That is sad since I used ElephantSQL in the very early days. A part of my developer projects is ElephantSQL. The closing down could be the failure to monetize cloud database model and to mitigate any risk from security point of view.
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 :(