Draft, not yet published
PlanetScale vs self-hosted Postgres for an app that's outgrown its free tier
7 July 2026· 5 min read · by Stackbastion
Your free database tier is full, or about to be. Now you’re staring at PlanetScale’s paid plans and wondering if you should just run Postgres yourself on a cheap server. One is a polished managed service. The other is more control for less money, if you’re willing to do the work. Here’s the real trade.
First, a MySQL vs Postgres note
PlanetScale is built on MySQL and Vitess (the sharding tech behind YouTube’s database). It recently added a Postgres option too, but its heart and its scaling story are MySQL. If your app is already written against Postgres, moving to PlanetScale’s MySQL side means a dialect change: different types, different functions, some query rewrites.
So this isn’t only “managed vs self-hosted.” It can also be “switch database engines vs stay on Postgres.” Factor that in before you’re seduced by the marketing.
The cost, roughly
Approximate public pricing, mid-2026. Ballpark, not quotes.
| Option | Rough monthly cost | What you get |
|---|---|---|
| PlanetScale paid | Starts around $39/mo and climbs with usage and larger instances | Managed, scaled, backed up, branching, no server to run |
| Self-hosted Postgres on Hetzner | ~€5 to €45/mo for the server | A database you install, tune, back up, and monitor yourself |
| Managed Postgres (Neon, Supabase, RDS) | ~$10 to $100+/mo | A middle path: managed, but standard Postgres |
The headline gap is real. A Hetzner box that comfortably runs Postgres for a growing app is a few euros a month. PlanetScale’s entry paid plan is closer to 40 dollars and rises from there.
But like every hosting comparison, the cheap number only covers the server. It does not cover the hours.
What PlanetScale gives you that a bare server doesn’t
- Automatic backups and point-in-time recovery, managed for you.
- Connection handling at scale. Its architecture is built to survive lots of connections, a place where naive Postgres setups fall over.
- Schema branching. You can branch your schema like Git, test a migration, and merge it. Genuinely useful and hard to replicate yourself.
- Horizontal scaling. Vitess can shard across many machines when you get truly big. Most apps never need this, but if you do, it’s a real advantage.
- No 2am pager. If a node dies, that’s their problem, not yours.
Running Postgres yourself, all of that is on you. You install it, tune shared_buffers and connection limits, set up PgBouncer for pooling, configure pgBackRest for backups, and wire up monitoring so you know before your users do when disk fills up.
When self-hosted Postgres is the smart pick
Choose self-hosted if:
- Your app is already on Postgres and you don’t want a dialect migration.
- Your data fits comfortably on one server, which for most apps means well into millions of rows.
- You’re comfortable on Linux, or ready to learn, and the monthly saving matters.
- You value owning your data on a plain, portable Postgres with no vendor-specific features locking you in.
The catch is honest and worth repeating: you are now the database administrator. Backups only exist if you set them up, and they only work if you test the restore. A backup you’ve never restored is a rumor. Monitoring only alerts you if you configured it. This is real, ongoing responsibility, not a one-time setup.
When PlanetScale is worth the money
Choose PlanetScale if:
- You expect to scale big and fast, and want sharding handled for you.
- You want schema branching and a strong developer workflow.
- You’d rather pay 40-plus dollars a month than own database operations.
- A MySQL/Vitess dialect is fine for your app, or you’re starting fresh.
There’s no shame in paying for this. Database operations is a real job, and PlanetScale does it well. The question is only whether your app needs that much machinery yet. Most apps outgrowing a free tier don’t need Vitess-scale sharding. They need a solid, backed-up, monitored Postgres, which is a smaller problem than PlanetScale is built to solve.
Or, we do it for you
If you want plain Postgres on a cheap server but not the DBA job that comes with it, that’s exactly what we run: tuned Postgres, PgBouncer pooling, tested backups with point-in-time recovery, and monitoring, with a named human on call. See our pricing. For a look at the managed Postgres field, read managed Postgres providers compared.
FAQ
Do I have to switch from Postgres to MySQL to use PlanetScale?
Historically yes, since PlanetScale is a MySQL platform. It now offers a Postgres option too, but its scaling story is strongest on the MySQL/Vitess side. If staying on Postgres matters to you, weigh that carefully, because a dialect migration is real work and a source of subtle bugs.
Is self-hosted Postgres safe for production?
Yes, Postgres runs enormous production systems. “Safe” depends on you, not the database. It’s safe if you set up tested backups, connection pooling, monitoring, and security patches. It’s a loaded gun if you install it and forget it. The database is reliable; the operations around it are the risk.
At what point does self-hosting stop being worth it?
When your data or traffic outgrows a single beefy server and you’d need to shard, or when the operations burden costs you more in time and stress than a managed plan costs in money. For many apps that point is far away. One well-sized server handles a lot before you hit a real wall.
What about managed Postgres like Neon or RDS instead?
That’s the middle path, and often the right one. You get standard Postgres (no dialect switch) plus managed backups and scaling, for somewhere between the cost of self-hosting and PlanetScale. If you like Postgres but don’t want to run it yourself, a managed Postgres provider is usually a better fit than switching to PlanetScale’s MySQL.