Writing
Notes on databases, and on systems that fail quietly.
The PostgreSQL pieces come with a runnable benchmark: a fixture, the before and after statements, and the result file the numbers on the page are read from. The rest come from production work, where the lesson was usually that a failure had been rendering as success.
By subject
2026
- PostgreSQL
A benchmark with no network in it measures the floor
A cascade delete that took seven minutes in production is a barely-visible win on my laptop. Measuring the per-statement cost showed why, and why a local number here is a floor rather than the size of the fix.
4 min read · with a runnable benchmark
- PostgreSQL
An array parameter of the wrong width
The same id list, one type wider than the column, costs two hundred times as much. PostgreSQL explains both statements with the identical plan, and EXPLAIN reports the same buffers.
5 min read · with a runnable benchmark
In progress
Subjects I am working on, listed so the direction of travel is visible. This is the one place here where something is stated that has not been measured, so it deliberately carries no numbers: a plan is not a claim, and a figure with nothing behind it would undo the point of everything above it on this page.
- PostgreSQLPlanned
The index the planner would not use because the types differed
When a column and a parameter are different numeric types, what happens to an index that exists on the column?
Sits beside the array-parameter piece and closes the loop on it: the same cast that loses the hash also disqualifies the index, and both are invisible in the plan.
- PostgreSQLPlanned
A CTE that the planner inlined, and then ran once per row
When does a common table expression stop being a materialisation boundary, and what does the planner do with the subtree afterwards?
Inlining changed the meaning of every CTE written before it, and the failure looks like an ordinary plan. MATERIALIZED is the fix; noticing is the hard part.
- PostgreSQLPlanned
Counting a large table without counting a large table
What are the options for a count a screen needs on every render, and what does each one cost on the write side?
Exact counts, planner estimates, incremental counters and triggers fail in genuinely different ways, and the usual advice picks one without measuring what it does to writes.
- RailsPlanned
Maintaining a denormalised column that nobody reads
How do you establish that a cache column or a recursive maintenance trigger has no consumers?
Deleting it is easy once you know. Finding out is the hard part, and the technique — searching for readers rather than for the writer — transfers to every denormalisation.
- ReliabilityBeing written
A failed read is not an empty list
How do you make three states — still loading, the read failed, and there genuinely are none — render distinguishably?
Several products converged on the same defect independently. It is the most common bug nobody reports, because the broken state looks like a quiet day.
- ReliabilityReproduced, not yet written up
The lock that could never be released, because a zero is a process group
What does probing an empty lock file for liveness actually ask the kernel, and how long can the answer go unnoticed?
A reproducible concurrency bug with a long silent outage behind it, and a general lesson about treating any error as proof of death.
- ReliabilityBeing written
An approval that charged the customer twice
How does a checkout path hand a buyer a second subscription without any single step being wrong?
The bug points in the customer’s favour, so nobody reports it — which is the whole class this category exists to describe.
- ReliabilityPlanned
One alert per bug, not one per occurrence
How do you fingerprint failures so a recurring bug reopens its own issue instead of filing a new one on every poll?
The normalisation trade-off — merging two bugs into one issue versus splitting one bug into thousands — has a right answer that is not the obvious one.
- Agent systemsPlanned
A watchdog that shares a failure domain with what it watches
How do you supervise a component when the supervisor resolves its own configuration through that same component?
Easy to state, easy to violate, and the violation looks like normal operation. The useful part is the cheap tells that it has already happened.
- ArchitecturePlanned
Coverage is a smoke detector, and one number lies in both directions
Why does a repo-wide coverage percentage tell you nothing, and what does a gate per layer change?
A repowide figure averaged a fully tested core against components needing a browser, and read as healthy while the rules the product existed for had no test at all.
Want one of these sooner, or something adjacent to it? hello@farol.dev