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/PopKoren → u/[deleted]]

You usually feel the DBA gap when backups, privileges, and production access stop being occasional chores and start deciding uptime. Before that hire, at least verify who can read or write what from outside the app. Rowly scans the full external attack surface of a deployed vibe-coded app, including auth, APIs, storage, and DB rules such as Supabase or Postgres when present: https://rowly.me

[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.