A Postgres guide told startups to normalize their schema first. HN said monitoring should come before that

A guide built in three tiers, with real thresholds attached

Hatchet's Postgres survival guide structures its advice as a progression: foundational schema and query hygiene first, intermediate query optimization and maintenance second, advanced scaling techniques last. It's not abstract advice — it attaches concrete numbers to each recommendation. Sequential scans start becoming a real problem past roughly 20,000 rows. Autovacuum runs lasting over an hour signal the vacuum settings need tuning before dead-tuple bloat catches up with the table. The guide pushes always using primary keys, timestamptz, and identity columns from day one; using CREATE INDEX CONCURRENTLY on any table large enough to matter, so index builds don't lock writes; keeping transactions short to minimize row-lock contention; and batching inserts, which the guide claims can deliver roughly a 10x throughput improvement over row-by-row writes. For higher-scale advice, it recommends partitioning time-series data so autovacuum can manage partitions independently and old data can be dropped instantly instead of deleted row by row, plus using triggers with batched backfills for large table migrations rather than one long-running ALTER TABLE.

The failure mode the guide undersells

The most substantive pushback in the 181-comment thread came from a commenter who'd been early at a Postgres-reliant startup: "I think this post doesn't put enough focus on monitoring and alerting. Postgres has a few key failure modes that you want to avoid ever happening, and you can use alerting to get early warning that you're [in] danger of it happening." Their concrete example: AWS will email you as a database approaches transaction ID wraparound — a genuinely catastrophic Postgres failure mode where the database's internal transaction counter runs out of room and can force the database offline to protect data integrity. "In a startup that email is very likely to be missed, especially if it's sent on Boxing Day. You want whatever AWS is watching to send you that email to be something connected to a pager." The point isn't that the guide's schema and indexing advice is wrong — it's that schema mistakes degrade performance gradually and give you time to notice; wraparound and similar failure modes give almost no warning and can take a production database down outright, so alerting infrastructure deserves to rank above stylistic schema choices, not below them.

A second commenter agreed with the guide's own starting point — "To this article's credit, it does start out with normalization and design!" — while flagging the same underlying pattern the wraparound critique points at: normalization gets under-emphasized in practice across the industry, not just in this one guide, because "we let our ORM build" the schema by default and nobody revisits it until performance problems force the issue.

The gap between what a guide teaches and what breaks in production

The backup-strategy question raised elsewhere in the thread follows the same pattern: one reader asked whether backups shouldn't be one of the very first things any team sets up, treating high availability as a later "nice to have" but backups as day-one non-negotiable the moment there's a production database at all. Taken together, the thread's critique of Hatchet's guide isn't that the technical content is wrong — it's a sequencing argument: a guide organized around performance tiers (schema → optimization → scale) reads naturally to an engineer, but the actual order startups get burned in practice is closer to (backups → alerting → everything else), because the failure modes that end companies aren't slow queries, they're the ones nobody was watching for until it was too late to fix quietly.