What PostgreSQL Practitioners Actually Complain About

Between 2020 and 2025 we sampled PostgreSQL problem reports from five kinds of source: Stack Overflow, DBA StackExchange, the r/PostgreSQL, r/database and r/devops subreddits, the pgsql-general and pgsql-performance mailing lists, and practitioner blogs including Percona, Citus, pganalyze, Cybertec and EDB. Each thread, post or article was treated as one problem signal. Signals were normalised into canonical problem statements, deduplicated, and classified into a fixed taxonomy of thirteen categories. The emphasis throughout is PostgreSQL 13 to 17.

The unit matters more than the number, so it is worth stating plainly: every percentage below is a share of problem signals, not a share of anyone’s time, budget, or incident count. If a category accounts for 15% of signals, that means roughly fifteen of every hundred problems people wrote about publicly fell into it. It does not mean fifteen percent of a DBA’s week. We have seen that kind of figure quoted as though it were a time measurement, and it is not one.

This is a sampling study rather than a census, and it carries the bias of its sources. Public forums over-represent problems people are willing to ask about in public and under-represent two categories: problems that are well enough understood that nobody needs to ask, and problems resolved quietly through paid support contracts. A category that is genuinely painful but commercially supported will look smaller here than it is. We would rather state that than let a reader discover it.

What the method is good for is relative weight. Which failure modes recur, across audiences that have no reason to coordinate, over a five-year window — that signal is robust even where the absolute figures are estimates.

The taxonomy was fixed before classification rather than derived from it, so that signals could not be quietly reshaped to fit an emerging story. Nine of the thirteen categories are direct contributors to performance degradation, query runtime volatility, or excessive consumption of memory, CPU and I/O. The remaining four — replication and high availability, monitoring gaps, maintenance scheduling, and capacity planning — hurt operators without necessarily slowing a query down.

Beginner SQL syntax questions, ORM configuration issues with no PostgreSQL component, academic exercises, and pure application bugs were excluded. What remains is production behaviour.

Weighted across all five source types, normalised to sum to one hundred. Figures are sampling-based estimates.

Autovacuum, bloat and dead tuples (15.0%) is the single largest category. PostgreSQL’s MVCC architecture creates a new row version on every UPDATE and marks the old one dead; this is by design and cannot be removed without replacing the storage engine. When autovacuum cannot keep pace — because of conservative defaults, long-running transactions, or replication slots holding back cleanup — table and index bloat accelerate, which wastes storage, inflates I/O, and degrades every query touching the affected relations. In the extreme case transaction ID wraparound takes the database read-only.

Suboptimal query planning (13.2%) is second and behaves differently: it arrives without warning. The planner depends on statistics that go stale, lack cross-column correlation, or simply estimate cardinality badly. A sequential scan chosen instead of an index scan, or a nested loop instead of a hash join, can change a runtime by orders of magnitude with no code deployment and no change in data volume. Approximately 15 to 20% of production slowdowns in our sample were attributed to an unexpected plan change rather than to more data or more load. PostgreSQL offers no native plan pinning, so there is no supported way to hold a good plan in place.

Indexing (12.8%) completes the group. Missing indexes force sequential scans on queries that should be selective; excess indexes slow every write and consume storage; wrong index types produce indexes the planner declines to use. Unlike the first two, this category is not self-correcting in either direction — an index set drifts out of alignment with a workload gradually, and only a deliberate review brings it back.

Together these three account for roughly 41% of all sampled signals. They also share a property worth noting: none of them is a bug. Each is the predictable consequence of a design decision interacting with a workload that changed after the decision was made.

The variation between sources is not noise; it tracks who is asking. Stack Overflow skews toward indexing (16%) and query planning (14%) — developers meet PostgreSQL through queries, so they see application-facing symptoms. Configuration ranks higher there too, largely because Stack Overflow users are more often running defaults.

DBA StackExchange is more evenly spread, with query planning at 15%, indexing at 14% and bloat at 13%: people who own the full lifecycle encounter maintenance as well as symptoms. Reddit leads with bloat (16%) and replication (12%), reflecting an audience of SREs and senior operators who discuss production incidents, and who discuss failures more openly than a formal Q&A site invites.

The mailing lists lean hardest toward bloat (18%) and replication (14%) — the deepest operational problems reach the official channels. Technical blogs mirror the mailing lists, because authors write about what is hardest to solve and most universally relevant.

Four audiences with different vantage points, and the same three categories at the top of all of them. That agreement is the most useful thing in the dataset.

A reasonable question is why a mature database with an active community still generates the same complaints for five years. The answer differs by category, and in each case it is structural rather than a matter of neglect.

Bloat persists because MVCC is not optional and autovacuum’s defaults are deliberately conservative — a scale factor of 0.2 and a threshold of 50 rows exist to avoid disturbing production workloads, which makes them inadequate for high-write tables by construction. Tuning them correctly is per-table work that depends on the write pattern of each table.

Plan instability persists because the planner is a cost model fed by sampled statistics. Improving the model does not remove the failure mode; it moves it. And without plan pinning, a correct plan cannot be preserved across a statistics refresh.

Index drift persists because nothing in the database notices that a workload has changed shape. The information needed to spot a missing or redundant index is available in the catalogues, but assembling it is a periodic manual exercise that competes with everything else on a DBA’s list.

The common thread is that each problem requires continuous attention to a moving target, using signals that exist but are scattered. That is a description of an operational gap, not of a defect.