The Startup's Postgres Survival Guide: What HN Is Saying About Hatchet's Battle-Tested Advice

Alexander Belanger, co-founder of Hatchet, published The startup's Postgres survival guide yesterday and it hit the Hacker News front page with 135 points. The post distills two years of production Postgres battles into a structured reference, and the HN discussion that followed added a dozen real-world corrections and expansions. Here is what the article covers, what the community added, and what it means for teams still learning to keep Postgres upright.

What the Guide Covers#

The guide is organized into three tiers: simple stuff (schemas, queries, indexes, migrations, connections), intermediate (query planner, bulk writes, autovacuum), and advanced (FOR UPDATE SKIP LOCKED, partitioning, large table migrations). Belanger writes from the position that most startup engineers start knowing "if a query is slow, you need an index" and need a path from there to actually running Postgres at scale.

The concrete advice is hard to argue with. Use identity columns or built-in UUIDs for primary keys. Always use timestamptz. Keep transactions short. Use CREATE INDEX CONCURRENTLY to avoid locking writes. Default autovacuum settings can kill your database. Belanger demonstrates real throughput numbers: batching writes can 10x your insert performance, and FOR UPDATE SKIP LOCKED is the right primitive for implementing a job queue directly in Postgres.

What makes the guide useful is that it explains the why behind each rule. The autovacuum section walks through dead tuples, transaction ID wraparound, and why monitoring autovacuum runtimes matters. The query planner section frames seq scans as an economic tradeoff, not a failure: sometimes Postgres estimates a sequential scan is cheaper than the index + heap lookups, and you need to accept that or restructure the query.

What HN Is Saying#

The discussion on the HN thread produced substantive pushback and additions across several areas.

Monitoring and alerting. The top comment from thundergolfer noted the guide focuses on prevention but skips detection: "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 are in danger of it happening." This is a fair gap. A survival guide should include what to watch for beyond autovacuum runtimes - connection pool exhaustion, replication lag, and growing dead tuple ratios.

Backup and restore. theallan pointed out the obvious omission: "Should one of the first things you do with a database not be to have a backup strategy?" Backup and restore are absent from the guide. For a startup, a production database without a verified restore plan is one deploy away from losing everything.

Cascading deletes. mjr00 pushed back on Belanger's recommendation to use foreign keys with cascading deletes: "I hate cascades, for a very simple reason: at most places, the person who set up the cascade is not the person debugging the accidental delete six months later." This is a real tension. Cascading deletes simplify correct cleanup at low volume, but they make unintended data loss silent and hard to trace.

Cost of Postgres for bootstrapping. hmokiguess raised a common frustration: "Postgres is my favorite thing, but I find it is prohibitively costly when bootstrapping something that is lean and frugal. I end up with a mixture of DynamoDB, S3, DuckDB on S3, and SQLite." At roughly $15-50/month for a managed Postgres instance (depending on provider), the cost floor is real for pre-revenue founders. The counterargument: SQLite and DuckDB do not give you the same concurrency model, and DynamoDB shifts the complexity to your application layer.

Stored functions and connection pooling. traceroute66 searched for "function" and found zero results, criticizing the omission. ComputerGuru added practical corrections: use uuidv7 (not uuid v4) for better index performance, and always order locks deterministically by ID ascending to avoid deadlocks. groundzeros2015 questioned whether connection pooling can leak data between requests - a concern that external poolers like pgbouncer handle through session-level pooling, but worth being explicit about.

Matt from Hatchet (mrkaye97) chimed in with a practical addendum: performing joins in application memory has worked well for them in specific cases where the alternative is a single overcomplicated query. This reinforces the broader theme of the guide - Postgres is powerful, but knowing when not to use it for everything is part of the survival skillset.

The Bigger Picture#

The guide and the discussion together paint a realistic picture of running Postgres in a startup. The database will not kill you early, but it will find every shortcut you took as you grow. The comment thread surfaced real gaps in the original post - monitoring, backup/restore, stored functions, lock ordering - and the author engaged directly, which is how good operational knowledge gets built.

For teams building on Postgres today, the core takeaway is that the smooth path looks like this:

• Start with a sensible schema (normalized, with primary keys, timestamptz, and foreign keys where they make sense)
• Add monitoring early - track connection counts, autovacuum runtime, replication lag, and the ratio of dead to live tuples
• Test your backups - a restore that has never been exercised is not a backup
• Batch your writes - 10x throughput with the same hardware is available for the taking
• Understand the query planner - it is a leaky abstraction, and EXPLAIN ANALYZE is your debugging friend
• Do not over-index - indexes have write overhead, and more is not better

DevDigest has covered Postgres operational patterns extensively. The Neon Postgres review covers the serverless hosting model that many startups choose today. The pgrust rewrite analysis explores what it means to reimplement Postgres in Rust. And the pgdog sharding proxy post covers what happens when one Postgres instance is no longer enough.

Sources#

• The startup's Postgres survival guide - the article itself, published 2026-07-22
• HN discussion - 62 comments, pulled 135 points
• PostgreSQL documentation - linked from the article as the comprehensive reference
• Hatchet blog - additional posts on Postgres partitioning and fast inserts from the same author
• supabase/agent-skills - recommended by the author for teams using AI to write queries
• Postgres autovacuum tuning - external reference linked from the article
• EXPLAIN ANALYZE visualizer - tool linked in the query planner section

Continue Reading#

• Neon Postgres in 2026: Review and Setup for AI App Builders - serverless Postgres for modern apps
• pgrust Passes 100% of Postgres Regression Tests: What the Rust Rewrite Actually Means - HN analysis of a Postgres rewrite in Rust
• Postgres 19 Beta Features - what is coming in the next major Postgres release
• SQLite Production Tips from Julia Evans - the lighter-weight alternative, and when it makes sense for startups
• Vector Database Comparison for RAG and AI Agents - how Postgres with pgvector stacks up against purpose-built vector databases