ElephantSQL Is Shutting Down

Original Article ↗ Hacker News Discussion ↗

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.