ElephantSQL Is Shutting Down | Hacker News Reader

ElephantSQL Is Shutting Down

elephantsql.com

163 pointsjonbaer119 comments

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 :(

The service is good but it was definitely not clear upfront about the postgresql version you were getting when selecting a region / provider.

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)

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?

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.

Evidently not, as few are willing to pay a large premium for them.

Evidently? Clarify please.

I imagine they meant: evidently not, because ElephantSQL is shutting down their service.

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.

Large premium? LOL! It is AWS you pay a large premium for.

> 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".

Insert LLM-generated variation thereof.

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.

> If AWS goes down, and it does

Rarely. And never if you've setup your environment across multiple regions.

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.

AWS can continue to provide you a product that consistently loses money because they have a gazillion million dollars.

They have the ability to kill comeptition by losing money until they go broke first.

For AWS such services bring network effect, and pay back in other segments of ecosystem.

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).

Haha.. That matches what I experienced. It literally disappeared from everywhere but actually just kept on running.

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.

This might help people when looking for an alternative.

https://wheretohostmy.app/?tech=%5B%22postgresql%22%5D

It's a side project I'm currently building so hearing some feedback is highly appreciated.

You're missing Scaleway as a provider I think.

Thanks! Will be adding.

Also Vultr https://www.vultr.com/products/managed-databases/postgresql/

Thanks, on my list now.

Be more careful about spreading misinformation, as both that story as well as the original contain posts from mods which explain it was bullshit.

https://www.vultr.com/news/a-note-about-vultrs-terms-of-serv...

drop the array and quotes in the url to make it prettier :)

Good point, the library I'm using just encodes the array in JSON but I may be able to switch to a comma separated list.

Hey zach, any update on your eyesight?

great idea! thAnks!

Glad you like it.

Fly.io also seems to be missing. Great for Elixir and Rails. Pretty great Heroku replacement

I use Gigalixir to host Elixir apps. It's more or less a drop-in Heroku replacement and it's worked really well for me.

Fly.io is covered. Here's the list of all hosting services currently supported:

https://wheretohostmy.app/services

We're not really a managed Postgres service, for what it's worth (we like Supabase a lot for hardcore managed Postgres).

I don't think anybody said that Fly.io is/has a managed Postgres service.

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?

Hahaha.

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

Sell the shovels, as they say. :)

What has gotten more complicated that used to be simpler in AWS?

I started with AWS pretty early.

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.

Like EC2 Classic? 2000s-era?

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.

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

It seems a bit odd to me that it's hard to manage a database.

It's just a collection of binaries configured with a few pages of text. The configuration should be fairly similar for a typical setup.

So why is it complex?

I mean, is it a fundamental complexity, or is it more like "nobody bothered to write an easy configuration script", or is it learned helplessness?

If the primary fails, will the replica fail over? How do you know?

Are the backups working? Who's checking?

Can anyone delete a directory when tired at 6PM on a Friday?

https://www.youtube.com/watch?v=tLdRBsuvVKc

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.

There's a partial description of the UI, but it's still unclear: https://docs.digitalocean.com/products/databases/postgresql/...

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

Sad but if you are going to shut something down this is the correct way so kudos.

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.

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.

Because RDS forces you to deal with the AWS behemouth instead if just changing your database connect parameters.

Care to elaborate?

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.

Well put, that's in essence what I meant.

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.

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.

Also Cloudflare just released the GA of Hyperdrive which makes it even more reasonable to use Postgres with them. Also it's free!

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

What? RDS supports username+password authentication for the database connection

That’s true, though you have to engage with the behemoth to get to that point.

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.

Supabase provides a lot of added value regarding tools and auth with SSO, so it’s more than just Postgres.

https://itsjustpostgres.com

;)

I know you’re joking around, but it’s not though… it’s GoTrue, Storage, Realtime, Kong, PostgREST, etc.

For analytics, the database can be anywhere and the niche providers offer multiplicative performance/cost gains.

I had good experience with Aiven in the past, we needed something located in the EU: https://aiven.io/

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.

They also have (or had? That was a few years ago) pretty good support

One year ago I created this list and demo of databases that are "free forever". I wonder how long it will take until none are left.

https://free-databases.vercel.app

Depends on how long those companies want to keep paying for something they're giving away for free.

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.

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?

In theory (!), yes.

It's something you'd need to trial though, perhaps a few times even.

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.

> Our postgres db is about 2TB and pgdump stopped being viable a long time ago.

Due to the time it takes to export, or because it can't handle a database of that size at all?

I'd assume they mean time to export, while 2TB is a substantial database, it's not pushing postgres limits.

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.

gov.uk did a good writeup of their 11 second migration of a 400gb database with ~1000 read/writes per second:

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.

Great write-up; their minimum would be O(DNS_SWAP + REPLICATION_LAG), though, so ~11s, if DMS 10s delay holds!

Set up replication, DNS switchover, done.

Takes some research but not rocket science.

1. pg_dump the old database

2. pg_restore to the new database

3. setup replication between the two databases

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

I was a "customer" since they had a free tier for my occasional hobby projects, the only free tier I found. Anyone else offering this?

Supabase or Neon Tech both have a form of free postgres. Not the same kind of free tho, I also loved elephant sql free tier.

This is new to me:

  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?

Also 24h down each day it's a weird way of saying down the whole week.

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

Primary architect of Ubicloud PostgreSQL here. Thanks a lot for shout out!

I'd be happy to answer if anyone has any questions about our managed service.

Is there any plans to offer your manager service at Digital Ocean / Vultr in the US?

We are planning to open up US regions quite soon but we are mostly focusing on bare metal providers at this point so Digital Ocean is out of picture.

Starting with Hetzner US then?

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.

neon.tech has me impressed so far. supabase as well if you need a baas. render.com for a heroku-like postgres experience.

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.

For existing customers looking for an alternative you can check this: https://elest.io/open-source/postgresql

For anyone interested, I'm actually in the middle of building a spiritual successor to ElephantSQL for hobbyists:

https://mkdb.sh

It’s pretty hard to compete selling any managed service

Sad to see amazing service shut down

The Aiven company they have partnered with's website seems to be down. Bad omen.

Did you even read the link?

Yes, when you click on End of Life Customer Information it recommends moving to Aiven, which was down when I attempted (and still is).

Owned by RDS?

Reply on news.ycombinator.com