Managed Postgres providers compared
25 September 2026· 7 min read · by Aaradhya
You need a Postgres database for your app and the options all sound fine on their homepages. A serverless provider, a backend-as-a-service platform, a big cloud’s managed database, or just running it yourself. They’re not the same trade, and the right pick depends on what you actually need beyond “a place to put rows.” Here’s the honest comparison, by category rather than by brand, since the products in each category tend to share the same trade-offs.
The good news across all four: this is real Postgres. Your schema, your queries, your data are portable. The differences are in pricing shape, backups, extra features, and how much of your time each one costs.
The four at a glance
| Serverless Postgres | Backend-as-a-service platform | Big-cloud managed database | Self-hosted | |
|---|---|---|---|---|
| What it is | Postgres that scales to zero | Postgres plus auth/storage/realtime | A big cloud’s managed Postgres | Postgres you run on a VPS |
| Pricing shape | Usage-based, free tier, scales to zero | Plan + usage + compute | Instance-hours + storage + IO | Flat server cost + your time |
| Backups | Branching + PITR on paid | 7-day snapshots, PITR add-on | Automated + PITR | You set up (pgBackRest etc.) |
| Extra features | Branching, autoscale | Auth, Storage, Realtime, dashboard | Deep cloud-ecosystem integration | None, just the DB |
| Lock-in | Low (standard PG) | Low on DB, medium on extras | Low on DB, medium on cloud glue | None |
| Best for | Dev branches, spiky/low traffic | Full-stack apps wanting a toolkit | Teams already in that cloud | Cost control, steady apps |
Now the detail that actually matters.
Serverless Postgres
The pitch behind this category is serverless Postgres that scales to zero when idle and supports database branching, so you can spin up a copy of your database for a feature branch the way you branch code. That’s genuinely useful for development.
Cost is usage-based with a real free tier. For a low-traffic or bursty app it can be very cheap, because you don’t pay for a database sitting idle. The flip side: scale-to-zero means a cold start on the first query after idle, which adds latency you have to design around. And like any usage-based model, a busy month costs more, and it’s harder to predict.
Backups and point-in-time recovery come on paid tiers, along with the branching. Lock-in is low because it’s standard Postgres.
This category fits when you want cheap dev databases, branching, or a low-traffic app where scale-to-zero saves real money. It fits less well when you have steady, latency-sensitive traffic where cold starts hurt.
Backend-as-a-service platform
This category is Postgres plus a whole toolkit: authentication, file storage, realtime subscriptions, auto-generated APIs, and a nice dashboard. If you’re using all of that, it’s a lot of product for the price.
The catch is the same as any bundle: you pay for the whole toolkit even if you only need the database. And the extras (auth, storage, Row Level Security) are the parts that create mild lock-in, because moving off means re-homing them, not just the data. We broke down what a backend-as-a-service platform actually costs past the free tier separately, because the headline price hides the compute add-on.
Backups on the base paid plan are typically 7-day snapshots. Point-in-time recovery is usually a paid add-on. Budget for it if your data matters.
This category fits full-stack apps that use the toolkit. It’s a worse deal when all you need is a database and you’re paying for auth and storage you don’t touch.
Big-cloud managed database
A big cloud’s managed Postgres offering is mature, reliable, and integrates deeply with the rest of that cloud’s services. Automated backups and PITR are built in and solid.
The cost is billed on instance-hours, storage, and IO, and it adds up. This category is rarely the cheapest option, and big-cloud pricing is famously hard to predict until the bill arrives. There’s also the ecosystem tax: to use it well you’re usually in that cloud’s networking, security groups, and identity systems, plus the rest of its learning curve. That’s power if you need it and overhead if you don’t.
Lock-in on the database itself is low, but the surrounding cloud glue (networking, identity, other services your app leans on) creates real switching cost over time.
This category fits teams already living in that cloud who want managed Postgres next to their other services there. It’s overkill for a solo founder with one small app.
Self-hosted
Running Postgres yourself on a VPS is the cheapest in cash and the most expensive in time. A capable box is a few euros a month and the database runs on it for free. No usage meters, no per-GB egress, full control.
What you take on: backups, point-in-time recovery, monitoring, patching, connection pooling, and restores. None of it is exotic, but all of it is your job now, and the risk is the untested backup that silently failed. We laid out the real cost of self-hosting vs PaaS including the time.
Self-hosting fits when you know Linux, your app is steady, and you’ve actually set up and tested backups, not just installed Postgres. It’s the wrong call when your time is scarce and a bad backup would be a disaster.
How to actually choose
- Just want it to work, using the whole toolkit? A backend-as-a-service platform.
- Want cheap dev branches or a bursty low-traffic app? A serverless Postgres provider.
- Already deep in a big cloud? Its managed database.
- Want the lowest bill and you’ll do the ops (or pay someone to)? Self-hosted.
The mistake is picking on the free tier alone. All four categories have generous free or cheap starts. The real question is what happens at month twelve, with real users, when you need a restore. Decide on the backup story and the steady-state bill, not the getting-started experience.
Or, we do it for you
If “self-hosted, done right, without becoming a DBA” is the box you’d tick if you could, that’s exactly what we do: Postgres 17 on a VPS with tested backups, verified restores, connection pooling, and a named human on call, at a flat price. See our pricing.
FAQ
Which managed Postgres category is cheapest?
Self-hosted is cheapest in cash, often a few euros a month, but it costs your time for backups, monitoring, and patching. Among the managed options, a serverless provider can be very cheap for low or bursty traffic because it scales to zero. A big-cloud managed database is usually the most expensive. The real answer depends on your traffic shape and how you value your hours.
Is my data locked in with these options?
The database itself is standard Postgres across all four, so your schema and data are portable, you can pg_dump and move. The lock-in lives in the extras: a backend-as-a-service platform’s auth and storage, or the ecosystem glue around a big cloud’s managed database. Plan any future migration around those pieces, not the raw data.
Do all of these include point-in-time recovery?
Big-cloud managed databases typically include it. Serverless and backend-as-a-service platforms usually offer it on paid tiers, not always the base plan. Self-hosted has none until you set it up yourself with something like pgBackRest. Check the specific plan, because 7-day snapshot backups and true point-in-time recovery are not the same thing.
Should a solo founder use a big-cloud managed database?
Usually not. That category shines for teams already in that cloud who want managed Postgres beside their other services there. For a solo founder with one small app, the ecosystem learning curve and unpredictable billing outweigh the benefits. A serverless provider, a backend-as-a-service platform, or a well-run self-hosted setup are simpler fits.
Get a free production audit
15-point check, scored report back in 48 hours, free either way.