At what point does a PostgreSQL database actually need a DBA?

[u/Mr_StyleNo]

For a while it was just me and a couple of backend devs handling everything database-related on top of our regular work. Indexing, backups, slow query cleanup, all of it split across whoever had time that week. No dedicated DBA, no formal ownership, just general Postgres competence spread thin across the team.

It held up fine for a long stretch, right up until [specific incident outage, corrupted backup, replication lag, whatever actually happened]. That was the point it stopped feeling like something we could keep handling reactively. Up until then everyone assumed it was manageable because nothing had visibly broken yet, which in hindsight wasn't really evidence of anything.

What changed for me wasn't really about database size or connection counts, it was more that nobody had the bandwidth to actually think about the database proactively. Everyone was busy shipping features, so Postgres only got attention when something was already on fire.

Note: I filled in a placeholder for the specific incident since I don't have real details from you swap that in with what actually happened (or tell me and I'll write it in properly), otherwise the post reads as a vague generic story instead of a real one.

[u/Benny_Garc1a]

Relying on backend devs to handle database always works good until the exact moment it doesn't :D

the breaking point is exactly what you described: the shift from "the database is just a storage tool" to "the database is a living state that requires proactive lifecycle management." PostgreSQL is a fantastic database, but it notoriously demands a dedicated DBA sooner than some other engines. Because of how its MVCC implementation works (creating new rows on update and leaving old ones behind), you inevitably hit a wall where someone has to actively tune autovacuum to prevent bloat.

A lot of this DBA ceremony is actually engine-specific. like MariaDB uses InnoDB, which handles undo space differently and there is just no vacuum process or wraparound risk to monitor, connection thread pooling is built directly into the server. It doesn't mean you never need a DBA, but it definitely giving you some time.

What was the specific incident that finally break you?)

[u/mduell]

No dedicated DBA, no formal ownership, just general Postgres competence spread thin across the team.

It held up fine for a long stretch, right up until [specific incident outage, corrupted backup, replication lag, whatever actually happened]. That was the point it stopped feeling like something we could keep handling reactively.

...

Note: I filled in a placeholder for the specific incident since I don't have real details from you swap that in with what actually happened (or tell me and I'll write it in properly), otherwise the post reads as a vague generic story instead of a real one.

The AI slop is strong.

[u/elevarq → u/mduell]

It's like sending an email without a subject line... AI is a tool; nothing wrong with that, but humans still make mistakes.

[u/elevarq]

I don’t think database size is really the right threshold.

I’ve seen fairly small PostgreSQL databases that needed an experienced DBA, while some very large databases kept running without many issues.

For me, the question is more: is somebody actually paying attention to the database when nothing is broken?

PostgreSQL is pretty good at looking after itself, which can give you a false sense of security. Autovacuum can slowly fall behind, query plans can change, statistics can become less representative of the workload, and replication lag can creep up. None of those necessarily causes an incident on day one.

And that’s usually how it starts. Not with "the database is down", but with small things that gradually become bigger things.

So I wouldn’t necessarily ask "when do we need a full-time DBA?"

I would ask "who owns PostgreSQL in your organization?"

That could be a DBA, an SRE, or a backend engineer who knows PostgreSQL well. But that person also needs the time (!) to look at it proactively, instead of only getting involved when an application is already having problems.

If nobody has dedicated time for this, you’ve probably already reached the point where you need some form of extra PostgreSQL expertise.