Deep-dive technical articles, career growth strategies, and mindset lessons. Lessons learned from production engineering and life.
Content Type
Your habits as an engineer aren't shaped by courses and effort alone; they're shaped by the PRs, teammates, and incidents you sit next to every day.
For twenty years, every PostgreSQL process read one disk page at a time and waited. PostgreSQL 18 finally lets it ask for many pages at once. Here's what changed under the hood, and how to verify the gain on your own workload.
Adding a vector column and calling it a day works fine in a demo. In production, it means picking between HNSW and IVFFlat, understanding what "approximate" actually costs you in recall, and watching index build time and memory explode as your embedding table grows. A practical look at pgvector's index internals and the tradeoffs nobody mentions in the quickstart.
500 requests a second are hitting a dependency that is completely dead. Every one gets a clean timeout after 2 seconds, exactly as configured. And you are still down. Three patterns, stacked in order, timeouts and retries, circuit breakers and bulkheads, backpressure and load shedding, each one picking up exactly where the last one's guarantee runs out.
Your database CPU is at 20%, your slowest query is 12ms, your slow-query log is empty, and your p99 is three seconds. Five ways connection pooling breaks in serverless and autoscaled deployments, why each one disguises itself as something else, and what every fix actually costs.
Every major PostgreSQL release gets the "this changes everything" headline treatment. Here's the honest version: what specifically didn't work in PG18 that PG19 now fixes, feature by feature, with the real production tradeoffs — from REPACK CONCURRENTLY to SQL/PGQ to parallel autovacuum.
A network blip retries a payment request. Without an idempotency key, the customer is charged twice. Here is why retries are unavoidable, how idempotency keys make them safe, and when a blockchain indexer replaying the same block twice must not double-count it.
Every fast system you use eventually has to decide what to throw away. The Least Recently Used policy is the answer nearly all of them land on, here's the two-structure trick that makes it instant, and why Redis, your browser, and Postgres all quietly cheat on the textbook version at scale.
A routine ALTER TABLE queues behind one slow query — and every SELECT that arrives after it queues too, even though they'd normally run just fine together. This is the PostgreSQL locking mechanic behind some of the ugliest production outages, and the two settings that prevent it.