pyparsing’s backtracking was the latency ceiling (~3.2k parses/sec). How we identified it, built a hand-written recursive-descent parser with pyparsing as a live parity check, and caught 22 edge cases along the way.
The Rust card store held 96k printings, each owning its own heap-allocated strings — even though ‘Forest’ appears 130 times with the same set name and ‘Shock’ has the same oracle text across every printing. Replacing each unique string with a u32 ID cut the archived card data from 107 MB to 47 MB and the build-time heap from 205 MB to 145 MB.
Swapping cachetools for cachebox (a Rust-backed Python cache) required only a thin key-hashing compatibility wrapper. TTLCache operations went from 537 ns/op to 90 ns/op — a 6× gain for a one-line dependency change.
Why id:gruul was doing a full table scan and how encoding color identity as a 5-bit integer—twice, once in SQL and once in the Rust engine—fixed it with arithmetic that fits in a single CPU instruction.
Card search moved from PostgreSQL into a Rust extension via PyO3. The 76× speedup came not from clever SQL tuning but from eliminating the database round-trip entirely — and from hitting a ceiling that Python itself could not clear.
The /random_search endpoint ran two full-table queries on every request. A 10-minute TTL cache materialized the 30k preferred-printing list once; individual requests then did an in-memory sample. Zero DB round-trips on the hot path.
Two SQL hypotheses about DISTINCT ON key choice: UUID vs text, and whether DISTINCT ON the primary key does any real work. One hypothesis failed; two wins shipped.
ILIKE on a trigram-indexed column was spending ~40ms in the query planner for every ~3ms of execution. The fix was two lines of SQL and one line of Python — but finding it required understanding what the planner actually does with ILIKE.
Replacing a per-symbol replaceAll loop with a single regex pass and a Map lookup cut mana symbol conversion time by 47×. The mechanism, the benchmark, and a gotcha with stateful regex.
The magic.cards table carries indexes of every type PostgreSQL offers. A tour of trigram GIN for substring search, GIN for JSONB containment, B-tree for numerics, hash for exact-match fields, and an expression index that unlocks a color identity query that otherwise requires a full table scan.