Backend & data engineering
I find out why a query costs what it costs, then fix it and prove the fix.
Most of my work is PostgreSQL performance inside larger systems — a production Rails application, a service where a single request fans out into hundreds of statements. The interesting part is almost never the index. It is the plan the planner chose, the type it was handed, or a model callback doing a table scan nobody asked for.
I write that work up here, and every measurement in every article has a reproduction you can run.
Worked example
The same id list, one type wider than the column, cost 245x.
`= ANY($1::bigint[])` against an `int4` column cannot use a hash, so the array is walked once per row. The same query with the array cast to the column's own type is 300x faster and returns the same rows.
It is a one-line change to the parameter, and it is the kind of thing that survives review because the plan prints the same sentence either way.
Read the write-up, with the benchmark →244.505x · postgres:16-alpine · 3 rounds
Same result set from every arm. Reproduce it with npm run bench.
Selected work
All work →2026
Backend and database performance
A production Rails application where deletes took seven minutes
A template delete that had been timing out against a 30-second request ceiling was reduced from 133,973 queries and 387 seconds to 8,724 ms and 3,099 queries — and, more usefully, the pattern behind a dozen smaller incidents was named and fixed.
2025 – 2026
Design and implementation
Subscription billing where the dangerous bugs point the customer’s way
A billing package where every grant, spend and refund is idempotent by database constraint rather than by timing, webhook replays recover rather than double, and a double-charge path was found and closed before a customer hit it.
Writing
All writing →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.
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.