Managed PostgreSQL for Developers: What the Host Actually Takes Off Your Plate

You can have PostgreSQL running in about a minute. `apt install postgresql`, or a single line in a Docker compose file, and there's a database listening on 5432. That part was never the hard bit. The hard bit is the three years after that minute: the upgrade you keep postponing, the backup nobody has tested, the 2am page when connections run out. "Managed" is the word for handing that part to someone else, and it's worth knowing exactly what's inside it before you decide it's worth paying for.

Because "managed" isn't a single feature you can point at. It's a list of operational jobs that quietly move from your side of the line to the host's. This guide walks that list one item at a time: what each job is, what it costs when you own it, and where managed stops and your own work begins (the part most vendor pages skip). None of it is magic. It's just a question of whose weekend gets ruined when something breaks.

What "managed" actually means

The clearest way to define managed is by contrast. An unmanaged database is one where you own the whole server: the operating system, the Postgres process, the disk it writes to, the config file, the backups, the monitoring, and every upgrade for the life of the machine. It's yours down to the kernel. That's a fine choice, and sometimes the right one, but it means the database is now a system you operate, not just a thing you query.

A managed database draws the line higher up. The host owns everything beneath your data: the machine, the Postgres binary, the replication, the backup pipeline, the patch schedule. You own the data and everything you do to it: the schema, the queries, the indexes. You connect with a URL and write SQL; the layer underneath is somebody else's responsibility. This is what the acronyms are pointing at when a provider calls itself database as a service, or DBaaS. Everything below is a tour of what sits in that underneath layer, so the trade you're making is concrete rather than a vibe.

The chores that move off your plate

Here's the operational work a managed provider absorbs. If you've only ever used a database through an ORM, some of these are jobs you didn't know existed, which is rather the point. They don't announce themselves until the day they go wrong.

Provisioning and day-one setup

A raw Postgres install ships with defaults tuned for a laptop from a decade ago. Getting it production-ready means sizing `shared_buffers` and `work_mem` to the machine, setting up TLS so connections aren't in plaintext, creating roles with sane permissions, and locking down `pg_hba.conf` so the whole internet can't knock on the door. A managed instance arrives with this already done and tuned to the hardware it runs on. On Runsite that's a PostgreSQL 16 database you spin up in seconds, with TLS on by default, and the whole setup checklist is somebody else's checklist.

Backups and point-in-time recovery

Everyone agrees backups matter, right up until they find out theirs haven't run since March. Doing this properly is more than a nightly `pg_dump` to the same disk the database lives on, because that disk is exactly what fails. You want full snapshots stored somewhere else, plus continuous archiving of the write-ahead log so you can rewind to any second, not just to last midnight. That last capability, point-in-time recovery, is what turns an accidental `DROP TABLE users` at 3pm into a ten-minute restore instead of a resignation letter.

Managed handles both halves. Runsite takes a daily snapshot and streams WAL segments continuously, keeping recovery points for 7 to 30 days depending on plan, and a restore is picking a timestamp in the dashboard rather than a tense evening with the docs. If you want a second copy under your own control on top of that (belt and suspenders), you can automate Postgres backups to S3 and keep a portable dump in your own bucket. Managed backups are the host's promise; a copy you hold is yours to keep.

Connection pooling

Every Postgres connection is a real operating-system process with real memory behind it, so the server can only hold so many before it tips over. A busy web app with a handful of instances, each opening its own pool, blows through the limit fast, and the reward is `FATAL: sorry, too many clients already` in the logs while the site throws 500s. The standard fix is a pooler like PgBouncer sitting in front, multiplexing thousands of client connections onto a small, steady set of real ones. Running that yourself is one more process to deploy, tune, and keep alive.

Managed providers usually bundle the pooler in. Runsite runs PgBouncer built in, so you connect on port 6432 for the pooled endpoint instead of 5432 for a direct one, and the multiplexing happens without a second service to babysit. How the pooling modes differ and what each port actually promises is its own topic, covered in connection pooling with PgBouncer. It's not a cure-all, either, and you can still exhaust a pool by leaking connections in your own code, which is a different problem we'll come back to.

Version upgrades and security patches

Postgres ships a new major version every year and patches the supported ones regularly, some of those patches closing real security holes. Upgrading a major version by hand is genuinely fiddly. It can mean a dump-and-restore or a logical replication dance, with downtime to plan around, so on a self-run box it's the maintenance that slips quarter after quarter until you're stranded on a version that stopped getting security fixes two years ago. A managed platform handles patching and offers a supported upgrade path, so "we're on an unsupported version" stops being a sentence you say in a post-mortem.

Scaling and headroom

Traffic grows, and the box that was comfortable in January is wheezing by June. Self-hosted, adding CPU, memory, or disk means a maintenance window and a migration, and running out of disk mid-day is a genuine outage, since Postgres does not cope gracefully with a full volume. Managed turns this into a slider. Runsite does one-click vertical scaling for CPU and memory, and storage autoscaling so the disk grows before it fills rather than after. For read-heavy workloads, read replicas on the Business plan spread query load across more than one machine, which self-hosting can do too, at the cost of building and monitoring the replication yourself.

Monitoring and high availability

You can't fix what you can't see, so a production database needs eyes on connection counts, slow queries, memory pressure, disk headroom, and replication lag. Self-hosted, that's a Prometheus exporter, a dashboard, and alert rules you assemble and maintain. Managed gives you the metrics out of the box: Runsite surfaces connections, queries per second, memory, storage, and replication lag in a dashboard from the start. Underneath, redundant snapshots and replication mean a single failed disk isn't the end of your data, which is the sort of durability engineering that's tedious to get right and easy to get subtly wrong on your own.

Where managed stops

This is the part the brochures leave out, and it's the most useful thing to be clear about. Managed hosting gives you a healthy server. It does not give you a healthy schema. Everything above the data line is still entirely your job, and no amount of managing changes that.

• Your schema and data model are yours: how the tables relate, what you normalize, which constraints you enforce. A managed host will faithfully run a bad schema at full speed.
• Indexes are on you too. The host won't know that your busiest query does a sequential scan over two million rows because the column it filters on was never indexed.
• Slow queries and N+1 are code problems. An ORM that fires 300 queries to render one page doesn't get fixed by a bigger machine; it just gets expensively fast.
• Connections you leak stay your bug. Pooling raises the ceiling, but code that opens connections and never returns them will still hit it. Managed gives you the pooler, not the discipline.

That last one is worth sitting with, because it's the most common way people blame the database for something they're doing to it. If you've ever hit connection limits despite a pooler, the cause is usually in the application, and the walkthrough in too many clients already traces it back to source. The honest framing: managed takes the operating-a-server job off your plate completely, and leaves the using-a-database-well job exactly where it was. That's not a gap in the service. It's the line between infrastructure and your application, and it's supposed to be there.

Does that list justify the price?

Every job above is one you can do yourself on a cheap VPS, which is why the sticker price makes self-hosting look like the obvious win. The database bill was never the expensive part, though — the engineer's evening, the 2am page, and the week that goes into a major-version upgrade are. Whether that trade favours you depends on numbers specific to your team, so rather than hand-wave it here: self-hosted vs managed PostgreSQL prices each job by the hours it costs, adds the risk that never reaches an invoice, and lays out the cases where self-hosting genuinely still wins.

What to look for in a managed provider

Every major cloud has a managed Postgres offering now, from AWS RDS and Google Cloud SQL to newer entrants like Supabase and Neon, and they don't all draw the line in the same place. It's worth checking what's actually included versus what's an upsell. A short checklist to run any provider against:

• Point-in-time recovery, not just nightly dumps, with a retention window long enough to notice a problem before the backup rolls off.
• Connection pooling included, not a separate thing you deploy.
• The extensions you actually use, like PostGIS for geospatial, pgvector for embeddings, and pg_trgm for fuzzy search, supported rather than blocked.
• A scaling story that doesn't need a migration: vertical resize and storage autoscaling at minimum.
• Encryption at rest and in transit as defaults, not toggles you have to remember to switch on.
• Clear data residency and a Data Processing Agreement if you handle EU users, so compliance isn't an afterthought.
• A way to try it without a sales call or a credit card, so you can see the shape of it before committing.

How Runsite handles it

For a concrete example of where the line sits, managed PostgreSQL on Runsite covers the operational layer described above and gets out of the way of your SQL. You get a PostgreSQL 16 instance in seconds, daily backups with point-in-time recovery from continuous WAL archiving, PgBouncer pooling built in on port 6432, one-click vertical scaling with storage autoscaling, read replicas on Business, and a monitoring dashboard for the metrics that matter. The extensions people reach for, PostGIS, pgvector, and pg_trgm, are all there — storing and searching AI embeddings with pgvector works without a second system — and connections run over private networking with TLS by default.

Because the platform is EU-native, the database, its WAL archive, and every backup stay in a Frankfurt, Germany region and never cross an EU border, which is the residency question that EU hosting for developers unpacks in full. A signed GDPR Data Processing Agreement comes with every plan, no upcharge and no sales call, and the free tier is a 1 GB database with daily backups you can start on without a card, running for 30 days before it needs a paid plan. Put Redis in front to cache hot queries when read traffic climbs, and the pieces that talk to the database all sit in the same region.

The short version

Managed PostgreSQL isn't a feature; it's a boundary. On the host's side of it sit provisioning, backups and point-in-time recovery, pooling, upgrades, scaling, monitoring, and durability — the operational work that costs you evenings and attention when you own it, and costs you a line item when you don't. On your side sit the schema, the indexes, the queries, and the connections your code opens, and no host can take those off your plate because they're the actual application. Choosing managed is deciding you'd rather spend your scarce engineering time above that line than below it. For most teams shipping a product rather than running a database company, that's the easy call. Spin one up on the free tier and you'll feel where the line is within an afternoon.