two databases, one binary: duckdb for reads, sqlite for state

Mon, 08 Jun 2026 00:00:00 +0000

the tracking endpoint has exactly one job: say 202 and get out of the way. a beacon fires on someone else’s website, my server catches it, and the visitor is already three paragraphs into an article before my response even lands. nobody is waiting on that request — the whole point of a sendBeacon is that the page has already moved on. so the afternoon i read a flame graph and found the ingest handler parked inside a duckdb INSERT, holding a request open while the disk did its thing, i felt a very specific kind of stupid. i’d taken a fire-and-forget pixel and taught it to block on fsync.

fixing that is most of this post. but the fix only makes sense on top of a decision most tutorials would have talked me out of: i put two different databases in one small rust binary, on purpose.

clean and verified are different claims: a two-axis trust state machine in postgres

Mon, 11 May 2026 00:00:00 +0000

ask a language model for a line of tacitus in spanish and it will hand you a sentence. fluent, confident, correctly punctuated. and sometimes the sentence contains a word that no translator ever wrote — a word a scanner invented, when it read the á in a 1919 printing as the digit 4, or turned violento into violen10, and then a spell-checker came along afterward and smoothed the wreckage into something that looks like spanish.

the text is clean. it is not correct. and nothing about the way it reads tells you which.

databases on krtffl.dev

two databases, one binary: duckdb for reads, sqlite for state

clean and verified are different claims: a two-axis trust state machine in postgres