Every few months, you probably read about some obscure technique, technology, or language feature and think, “I should remember this exists.” Most of the time, that knowledge just sits there, taking up mental real estate. Occasionally, though, you hit a problem and realize you’ve been carrying around the exact solution for months without knowing it.
That happened to me with Node.js AsyncLocalStorage. I remember reading a blog post about it a while back and thinking, “That sounds useful; I have absolutely no use case for it.” Months went by, and that assessment held true—AsyncLocalStorage was a neat tool with nothing to unlock.
Then DrizzleORM’s logging limitations finally gave me the excuse I’d been waiting for.
The Problem
At Numeric, we use Drizzle as our fully-typed Postgres query builder. I’ll save the deeper discussion of why we chose Drizzle and how we think about our tools for another post, but long story short, for our core technologies, we like tools that don’t abstract away the thing they’re wrapping. One of our core engineering values is taking pride in extremely deep knowledge of our tools, and we consider SQL to be among our most critical. Drizzle’s query builder creates queries that are immediately intelligible to anyone who writes SQL, which is exactly what we want.
But Drizzle is still an early, beta product. That comes with some blind spots. Custom query logging is one of them.
For every database query, we need a canonical log line that includes:
A unique query key (for tracking specific queries across our codebase)
Execution time in milliseconds
The sanitized SQL query
... continue reading