{"id":22663,"date":"2026-07-24T09:58:29","date_gmt":"2026-07-24T09:58:29","guid":{"rendered":"https:\/\/scannn.com\/hatchet-%c2%b7-the-startups-postgres-survival-guide\/"},"modified":"2026-07-24T09:58:29","modified_gmt":"2026-07-24T09:58:29","slug":"hatchet-%c2%b7-the-startups-postgres-survival-guide","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/hatchet-%c2%b7-the-startups-postgres-survival-guide\/","title":{"rendered":"Hatchet \u00b7 The startup's Postgres survival guide"},"content":{"rendered":"\n
\n

Over the past half year or\u00a0so, I\u2019ve\u00a0been writing an\u00a0internal doc for our engineers trying to\u00a0distill two years of\u00a0Postgres battles into a\u00a0somewhat cohesive document. While I\u00a0love the Postgres manual<\/a>, I\u00a0find it\u2019s\u00a0hard to\u00a0turn to\u00a0when shit hits the fan because it\u2019s\u00a0just so\u00a0darn comprehensive. I\u00a0thought this might be\u00a0useful for others and would appreciate feedback (or\u00a0other tidbits that you\u2019ve\u00a0learned running Postgres in\u00a0production).<\/p>\n

Before starting Hatchet, while I\u00a0was familiar with SQL, the extent of\u00a0my\u00a0knowledge was basically: if\u00a0a\u00a0query is\u00a0slow, you need an\u00a0index. That\u2019s\u00a0the starting point for this doc; I\u2019m\u00a0going to\u00a0assume you\u2019re\u00a0familiar with SQL basics, rows, tables, and know roughly what an\u00a0index is.<\/p>\n

And if\u00a0Claude is\u00a0writing all of\u00a0your queries, this might be\u00a0a\u00a0waste of\u00a0time! I\u00a0recommend supabase\/agent-skills<\/a><\/em><\/p>\n

\n

A\u00a0quick note on\u00a0ORMs<\/a><\/h4>\n

This guide should still be\u00a0useful, but you might need to\u00a0translate some of\u00a0these tips into your ORM of\u00a0choice. Lots of\u00a0optimizations as\u00a0you scale just aren\u2019t\u00a0possible with ORMs unless you can break past the abstraction layer and write SQL.\u00a0You can do\u00a0this gracefully or\u00a0non-gracefully; Prisma TypedSQL<\/a> or\u00a0equivalents look interesting for this. We\u00a0use sqlc<\/code> at\u00a0Hatchet which gets us\u00a0very similar behavior; highly recommend if\u00a0you\u2019re\u00a0a\u00a0Go\u00a0stack.<\/p>\n

Table of\u00a0contents<\/a><\/h4>\n

The simple stuff: good reads, writes and\u00a0schemas<\/a><\/h3>\n

Let\u2019s\u00a0start with the basics: queries and schemas at\u00a0low volume.<\/p>\n

Writing a\u00a0good schema<\/a><\/h4>\n

After you\u2019re\u00a0deployed, schemas are by\u00a0far the hardest to\u00a0change moving forward, so\u00a0it\u2019s\u00a0worth spending some time on\u00a0them. I\u2019d\u00a0recommend building your schema iteratively: start with a\u00a0rough approximation for your tables and primary keys, then write some queries on\u00a0those tables based on\u00a0your application needs. You can approximate this with some questions: Is this a\u00a0high-read and\/or high-write table? What are the most common filters on\u00a0reads? Which columns am\u00a0I\u00a0updating the\u00a0most?<\/em><\/p>\n

If\u00a0you want to\u00a0be\u00a0more formal about it, you can look into database normalization<\/a> into 1NF\/2NF\/3NF, but I\u2019ve\u00a0found normal forms to\u00a0sometimes be\u00a0at\u00a0odds with query efficiency and ease of\u00a0use, which is\u00a0critical when you\u2019re\u00a0moving fast\u2014sometimes it\u2019s\u00a0just easier to\u00a0dump data into a\u00a0jsonb<\/code>\u00a0column.<\/p>\n

My\u00a0rules of\u00a0thumb for schemas\u00a0are:<\/p>\n