postgres

postgres is the default. every product i have built stores its state here, and almost everything i have learned the hard way about concurrency, i learned from it.

what does this blog cover about postgres?

concurrency bugs first. the textbook lost update — a read-modify-write vote handler that silently discarded 79% of every rating change under load, which is the kind of number that only shows up if you go looking. read committed does not mean what people assume it means, and that post is the proof.

then data modelling: encoding “may we publish this” and “how faithful is this text” as two orthogonal columns rather than one overloaded status enum, with check constraints as the structural backstop rather than a comment in the code.

and performance under a load that has not arrived yet — seeding a fake gone-viral database, running EXPLAIN ANALYZE over the hot paths, and finding the public stats page that was a denial-of-service i was hosting myself.

• clean and verified are different claims: a two-axis trust state machine in postgres — modelling 'may we publish this' and 'how faithful is this text' as two orthogonal postgres columns, with check constraints as a structural backstop
• i audited my side project like it was about to go viral (before it was) — seed a fake gone-viral database, EXPLAIN ANALYZE the hot paths, and find the public stats page that was a denial-of-service you host yourself
• the elo race that silently ate 79% of every vote — a textbook lost-update bug: a read-modify-write vote handler that lost 79% of every rating change under load
• sqlc + pgx over an orm: type-safe sql that fails at compile time — hand-written sql compiled to type-safe go, and why the orm in go.mod was dead code

related

the queries themselves live on the go side — sqlc + pgx over an orm — and the isolation boundary is covered under security .