Database Management Services: What Managed Actually Removes From Your Plate

A managed database service takes over the operational layer — provisioning, patching, backups, replication, failover — and leaves you the schema, the queries, and the data model. That division is clean, and knowing exactly where the line falls is more useful than any vendor comparison.

The pitch is usually framed as convenience, which undersells it. The real argument is that database operations is a specialism with a long tail of rare, expensive failures, and most teams will hit those failures perhaps twice — once with no experience, and once having learned from the first. Buying the operational layer is buying somebody else’s second time.

What the provider takes on
What stays yours regardless
When self-managing is the right answer
Evaluating an offering
The connection limit is the ceiling you meet first
A short decision rule
How this fits the rest of the stack
FAQ

What the provider takes on

Provisioning. A running instance in minutes rather than an afternoon of package installation and tuning.
Patching. Security updates applied on a schedule, usually in a maintenance window you choose.
Backups. Automatic, scheduled, retained, and — this is the part that matters — restorable through a documented path.
Replication and failover. A standby that can be promoted, without you writing the promotion logic.
Monitoring. Connection counts, query latency, disk usage, replication lag, surfaced without building a metrics stack first.
Baseline configuration. Sensible memory and connection settings for the instance size, rather than defaults from 2010.

The one worth paying for on its own is backups. Not because taking a backup is hard — pg_dump in a cron job is fifteen minutes of work — but because a backup nobody has ever restored is not a backup. Managed services make restore a documented operation that is exercised routinely, which is the property that actually saves you.

Point-in-time recovery is the version of this that is genuinely difficult to build yourself. Restoring to 14:32 last Tuesday, just before someone ran an UPDATE without a WHERE clause, requires continuous archiving of write-ahead logs and a tested replay procedure. Most self-managed setups have nightly dumps and nothing else, which means the answer to that incident is you lose the day.

What stays yours regardless

Managed does not mean absolved, and mistaking one for the other is where teams get hurt.

Schema design. Nobody else picks your data types, keys, or normalisation.
Indexes. The provider will not know that a query filters on status and created_at together.
Query performance. A sequential scan over ten million rows is slow on any infrastructure.
Connection management. Pool sizes, leaked transactions, and the arithmetic of instances multiplied by pool size are yours.
Access control. Which application user can read which table.
Data correctness. An application bug that writes wrong data writes it faithfully and backs it up faithfully.

The pattern in support tickets is consistent: a team moves to a managed service, performance does not improve, and the conclusion is that the service is bad. The service replaced the operations. It did not replace the missing index.

When self-managing is the right answer

It genuinely is, sometimes, and the honest cases are worth naming.

You need an extension or version the managed offering does not support. This is the most common legitimate reason. A specific PostgreSQL extension or a pinned version can simply rule out a hosted option.
Regulatory constraints on where data sits that no available managed region satisfies.
You already have the expertise on staff and it is not the bottleneck. A team with a real DBA runs Postgres well and knows it.
Scale where the economics invert. At large enough volume, the operational premium exceeds the cost of a dedicated team. That threshold is much higher than most teams estimate.
Development and testing. A local Docker container is the correct database for a laptop, and nobody should pay for a hosted instance to run unit tests.

What is not on that list: it is cheaper. The instance line item usually is cheaper self-managed. The total is not, once you count the hours spent on upgrades, the incident where replication lagged silently for a week, and the restore nobody had tested. Those costs are real; they just do not appear on an invoice, which is exactly why they get left out of the comparison.

Evaluating an offering

The questions that separate services, in rough order of how often they matter later:

What is the backup retention and can you do point-in-time recovery? Ask specifically. Nightly snapshots and PITR are different products.
How do you restore, and have you tried it? Run a restore during evaluation, not during an incident.
What is the connection limit for the plan? This is the ceiling you will actually hit first, ahead of CPU or disk.
Is it reachable privately? A database that must be exposed publicly for your application to reach it is a security problem you are being asked to accept.
What does an upgrade look like? Major version upgrades are the operation most likely to involve downtime.
How do you get your data out? A standard dump format is what makes leaving possible. If the export path is proprietary, that is worth knowing on day one rather than year three.

That last one is the most neglected. Portability is not a feature you use often, but knowing you could move is what keeps the relationship healthy — and a plain pg_dump or mysqldump is all it takes.

The connection limit is the ceiling you meet first

Worth its own section, because it surprises people who sized on CPU and memory.

Every plan has a maximum connection count, and it is usually a smaller number than expected. The arithmetic that matters is instances multiplied by pool size per instance, plus background workers, plus migrations, plus whatever a developer has open in a GUI client.

-- Postgres
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- MySQL
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

Autoscaling makes this sharper. Scaling the web tier from four instances to twenty multiplies the connection demand by five while each instance looks perfectly healthy, and the database is what falls over. A connection pooler in front — PgBouncer for Postgres, ProxySQL for MySQL — decouples the two, and it is the piece most teams add only after the first outage.

Check the limit for your plan before you need it, and check Max_used_connections occasionally. It is a two-second query that turns a future incident into a planned upgrade.

A short decision rule

Anything with users and data you cannot recreate — managed. The backup and restore path alone justifies it.
A specific extension or version requirement that rules out hosted — self-managed, deliberately, with a documented backup and restore procedure you have tested.
Local development and CI — a container. Do not pay for this.
Regulated data with no compliant region available — self-managed in the compliant place.
Everything else — managed, and spend the recovered time on indexes and queries, which is where the performance actually is.

How this fits the rest of the stack

RunxBuild’s managed databases are MySQL and Postgres, provisioned beside the services that use them, reachable over private networking rather than the public internet, with backups, user management, and a documented connection limit per plan. The database, the service, and the storage are separate line items rather than a bundle, which makes the sizing conversation concrete. Databases on RunxBuild covers creating and connecting, database backups on RunxBuild covers the retention side, and when you are working out what an application plus its database costs at a given size, the RunxBuild hosting calculator shows each part separately rather than as one monthly figure.

Useful related references:

FAQ

What does a managed database service actually do?

It takes over the operational layer: provisioning, security patching, scheduled backups, replication and failover, and baseline monitoring. Schema design, indexes, query performance, connection pooling, and access control remain your responsibility.

Is a managed database more expensive than self-hosting?

The instance line item usually is. The total often is not, once you count engineering hours spent on upgrades, monitoring setup, and incidents — plus the cost of a restore nobody had tested. Those costs are real but do not appear on an invoice, which is why comparisons tend to omit them.

When should I self-manage a database instead?

When you need an extension or version the managed offering does not support, when regulation dictates a location no provider offers, when you already have a DBA on staff, or for local development and CI where a container is the right answer.

What should I ask before choosing a database provider?

Backup retention and whether point-in-time recovery is available, what a restore actually involves, the connection limit for the plan, whether the instance is reachable privately rather than over the public internet, what a major version upgrade looks like, and how you export your data if you leave.

Why do managed databases run out of connections?

Because the limit is per plan and is usually lower than teams expect, while demand is instances multiplied by pool size plus workers plus admin sessions. Autoscaling the application multiplies it further. A connection pooler such as PgBouncer or ProxySQL decouples client connections from server ones.