Every managed PostgreSQL provider offers the same headline list: automated backups, monitoring, high availability, one-click provisioning. The list is real, and it is nearly useless for choosing between them, because the differences that will actually affect you sit in the operational details underneath — how many connections you get, what a restore really involves, who decides when you upgrade, and whether the database is reachable from the public internet.
This is a guide to those details. It names no provider and ranks nothing, because the right answer genuinely depends on what you are running, and because a comparison table that goes stale in six weeks is worse than no table at all.
Table of contents
- What managed actually buys you
- Connection limits are the first wall you hit
- Backups are a restore claim, not a backup claim
- Major version upgrades are the slow surprise
- Networking: public endpoint or private network
- Extensions, and the ones you will miss
- Reading the price properly
- How this fits the rest of the stack
- FAQ
What managed actually buys you
It is worth being precise about what you are paying for, because it is a shorter list than the marketing implies.
A managed PostgreSQL service takes over provisioning and initial configuration, minor version patching, backup scheduling, disk growth, failover if you pay for a replica, and the monitoring that tells you when something is wrong.
It does not take over your schema, your indexes, your query plans, your connection handling, your data model, or the decision about when to do a major version upgrade. Those remain entirely yours, and they are where nearly all real database problems come from.
That is not a criticism of managed databases. Patching and backups are exactly the work you want to hand off, because it is repetitive, easy to defer, and catastrophic to get wrong. Just do not buy one expecting it to fix a slow query.
Connection limits are the first wall you hit
PostgreSQL allocates a process per connection, which makes connections expensive in a way that surprises people arriving from other databases. Managed providers therefore cap the maximum connection count based on instance size, and on small instances that cap is low — often somewhere between 20 and 100.
That sounds like plenty until you count properly. A web application with a pool of 10, running four instances, is 40 connections. Add a background worker, a migration job, a monitoring agent and your own psql session, and a small instance is full.
The symptom is a fatal error saying there are too many clients already, and it usually appears the first time you scale the application horizontally, which is to say at exactly the moment things were going well.
So the questions are:
- What is the connection cap at the size I am buying, and at the size above it?
- Is a connection pooler included, or do I run one myself?
- Does the pooler support transaction mode, and do I know which of my features break in transaction mode? Prepared statements and session-level advisory locks are the usual casualties.
A provider that includes pooling and states the limit plainly is telling you they have thought about how their service is actually used.
Backups are a restore claim, not a backup claim
Everyone backs up. The differences are in what you can restore to, how long it takes, and where it lands.
Ask about point-in-time recovery specifically. Nightly snapshots mean your worst case is losing a day of writes. Point-in-time recovery over a retention window means your worst case is losing a few minutes. Those are very different products and they are often described with the same word.
Then ask the questions people skip:
- How long does a restore take for a database my size? Restoring 200GB is not instant, and knowing whether it is twenty minutes or four hours changes your incident plan.
- Does restoring create a new instance or overwrite the existing one? Almost always the former, which means a connection-string change is part of your recovery, and that belongs in the runbook rather than being discovered during the incident.
- Can I download a backup and take it elsewhere? If the answer is no, you have a lock-in problem worth knowing about before there is 500GB in there.
And then do the thing almost nobody does: restore one, into a throwaway instance, on a quiet Tuesday. A backup that has never been restored is a hypothesis.
Major version upgrades are the slow surprise
PostgreSQL releases a major version every year and supports each one for five. That means every managed database you create today has a forced migration somewhere in its future, and providers handle this very differently.
Some run the upgrade for you in a maintenance window. Some give you a button and a rollback path. Some give you a deadline and a documentation link. The one to watch for is the provider that will force-upgrade on their schedule, because a major version upgrade can change query plans, and a plan regression on a table that matters is not something you want to meet on somebody else’s calendar.
Worth asking: what happens when my version reaches end of life, how much notice do I get, and can I test the upgrade against a copy first? The last one is the important one. An upgrade you can rehearse against a restored snapshot is a routine task. One you cannot rehearse is a gamble.
Networking: public endpoint or private network
A great many managed databases are handed to you as a public hostname and a password. It works immediately, which is why it is the default, and it means your database’s front door is on the internet with authentication as the only barrier.
Better arrangements exist and are worth asking for:
- Private networking, where the database is reachable only from your own services. This is the right default for anything holding real data.
- Address allowlisting, which helps if your egress addresses are stable and does very little if they are not.
- Certificate verification, not merely encryption. Requiring TLS encrypts the connection without confirming who is on the other end. Full verification is the mode that actually resists an impostor.
The trade-off to know about: a database on a private network cannot be reached from your laptop, which is inconvenient exactly as often as it is protective. That is what bastion hosts and tunnels are for, and being mildly annoyed by it is the correct outcome.
Extensions, and the ones you will miss
Managed providers allow a fixed list of extensions, because some extensions can run arbitrary code and nobody operating a shared platform is going to permit that.
Check the list before you commit rather than after. The ones people most often need and most often assume:
- The statement statistics extension, for finding slow queries. Without it you are debugging performance blindfolded.
- Trigram search, which is what most projects actually need instead of a separate search cluster.
- Geospatial support, if there is any geography in your future.
- Cryptographic helpers, though random UUID generation is built in now and covers most of the common case.
Also ask whether you get a broadly privileged role or a genuinely restricted one, because that determines whether you can create extensions yourself or must file a request and wait.
Reading the price properly
The headline monthly figure is usually the compute. The bill is usually more than that, and the additions are predictable:
- Storage, priced per GB and often billed on allocated rather than used.
- Backup storage, sometimes free up to the database size and charged beyond it.
- Egress, which is where a database in one provider and an application in another gets expensive quietly.
- The replica, if you want failover. High availability is roughly double, because it is a second machine.
The practical move is to price the whole shape — database, application, storage, bandwidth — rather than the database alone. A cheap database with expensive egress is not cheap. It is cheap in the column you happened to be looking at.
How this fits the rest of the stack
The honest summary is that most managed PostgreSQL offerings are competent, and the thing that will actually hurt you is a detail you did not ask about: the connection cap you hit on your third application instance, the restore you had never rehearsed, the upgrade on somebody else’s schedule. Choose on those.
It also helps to see the numbers together rather than one at a time, since the database is rarely the only line. The RunxBuild hosting calculator lists the instance, the service that talks to it, storage and bandwidth as separate items. RunxBuild runs managed MySQL and Postgres with connection limits, backups, user management and private networking handled, on the same plan ladder as the services beside them, which keeps the database on the same private network as the application rather than on a public hostname.
Useful related references:
- Database management services, and what managed removes
- PostgreSQL backups that survive a real restore
- SQLite vs PostgreSQL: which one your project needs
- Databases on RunxBuild
- Connection limits on managed databases
- Managed database backups
FAQ
What should I look for in a PostgreSQL provider?
Connection limits at your instance size, whether point-in-time recovery is offered and how long a restore takes, who controls major version upgrades, whether the database can live on a private network, and which extensions are permitted. Those five predict your experience better than the feature list does.
Is managed PostgreSQL worth it over self-hosting?
For most teams, yes. What you are buying is patching, backup scheduling and disk management, which is exactly the work that gets deferred until it becomes an incident. What you are not buying is schema design or query performance, which stay yours either way.
How many connections does managed Postgres allow?
It scales with instance size and is often between 20 and 100 on small plans. Because PostgreSQL uses a process per connection, that number is lower than people expect, and horizontal scaling of your application is what usually exposes it. A connection pooler is the standard answer.
What is the difference between backups and point-in-time recovery?
A backup restores you to the moment the snapshot was taken, so the worst case is losing everything since last night. Point-in-time recovery replays the write-ahead log, so you can restore to a chosen moment inside the retention window and lose minutes instead.
Should my database be on a public endpoint?
Preferably not. A public hostname makes authentication the only barrier between the internet and your data. A private network limits reachability to your own services, which is inconvenient for laptop access and correct for everything else.