ElephantSQL Is Shutting Down

Original Article ↗ Hacker News Discussion ↗

A long‑running managed PostgreSQL service, ElephantSQL, is shutting down as competition from major cloud providers and specialized platforms intensifies. Commenters praise its simplicity, transparency, and free tier for hobby projects, but note how hard it is for a small, focused vendor to compete on price, features, and proximity to customer workloads against AWS, Azure, GCP, and newer players like Supabase and Neon. The thread also explores migration challenges (especially for large databases), alternative providers, and broader frustrations with the complexity and lock‑in of big cloud ecosystems.

Overall reaction to ElephantSQL shutdown

  • Many express sadness; ElephantSQL is seen as “cloud done right”: simple, transparent, low lock‑in, pleasant UI.
  • Some say this is the right way to shut down a service: long notice, clear timelines, and concrete guidance.
  • Others note this illustrates how hard it is for small, focused providers to survive in a crowded managed‑Postgres market.

Why small DBaaS providers struggle

  • Big clouds (AWS, GCP, Azure) bundle managed databases close to app workloads, reducing latency and egress cost; that makes off‑cloud DBaaS less attractive.
  • Large providers can run low‑margin or loss‑making services to maintain ecosystem lock‑in and network effects.
  • Running DBaaS across many regions and clouds is suspected to become uneconomical as scale or growth decline.
  • Some disagree that small providers are inherently unviable, arguing they can be successful at modest scale and don’t need to be “the” market leader.

Cloud provider trade-offs

  • Several complain about AWS complexity: account setup, IAM, networking, bewildering options and pricing opacity.
  • Others praise simplicity of alternatives like DigitalOcean or Azure’s “just give me a connection string” experience.
  • Debate on cost: some claim AWS is the expensive option; others argue customers won’t pay a “premium” for smaller providers.
  • Privacy and trust vs. hyperscalers vs. small/local providers is contested; no concrete evidence is provided either way.

Alternatives and free tiers

  • Suggested replacements: Aiven (explicitly recommended by ElephantSQL), Supabase, Neon, DigitalOcean, RDS, Ubicloud, DO/Vultr/Scaleway/Fly.io, plus comparison tools like wheretohostmy.app and lists of “free forever” databases.
  • Some miss ElephantSQL’s hobby‑friendly free tier; Supabase and Neon are cited as partial substitutes.
  • One person is building a hobbyist‑oriented “spiritual successor” service.

Migration, lock-in, and large databases

  • ElephantSQL’s own docs apparently only support pg_dump for migration, implying downtime for write traffic; this is criticized as lock‑in‑prone for large DBs.
  • Multiple comments stress that ability to set up replication out of a DBaaS is crucial to avoid downtime and vendor lock‑in.
  • Techniques mentioned: logical/physical replication, pg_basebackup, pg_upgrade, DNS cutover, and real‑world examples of sub‑minute downtime on hundreds‑GB databases.

Brownout/blackout shutdown design

  • The staged “brownout” month (increasing daily outages) followed by final “blackout” and data deletion is noted as harsh but effective to force attention.
  • Some confusion remains about the final “24h down each day” week and whether data export is still possible; this is left unclear.