Designing EventQL, an Event Query Language¶
When we built EventSourcingDB, we didn't just create a storage engine for events. We wanted to give developers the right tools to work with those events in ways that are both practical and efficient. Very early on, we realized something important: while projections are great for predefined, recurring questions, they don't cover everything. Sometimes you need answers on the fly.
You know those moments when you're debugging a production issue and want to see every event of a certain type within the last day? Or when you're exploring a new feature and want to check how often a specific command was issued, but no projection exists yet? Creating a new projection for that one-off need feels wrong. It takes time to model, deploy, and maintain – just for a question you might ask once.
That gap – between the recurring and the ad hoc – is where EventQL came from.
Why We Needed Our Own Query Language¶
From the beginning, we wrote EventSourcingDB's storage engine ourselves. It's not built on top of an existing database; it's a purpose-built event store. That meant we weren't constrained by someone else's query layer – but it also meant nothing existed out of the box.
Of course, we could have exposed only the raw event stream and left filtering to the client. But asking every user to pull the entire event history just to answer one question is painfully inefficient. We knew we needed server-side querying.
We also briefly considered simply reusing SQL. It's familiar, widely understood, and powerful. But we ran into two problems:
Conceptual mismatch. SQL evolved for relational tables, not for an append-only event log. Some SQL patterns don't make sense when your "records" are immutable facts with metadata and JSON payloads. Design inconsistencies. Over the years we've personally tripped over oddities in SQL's design. A classic example: queries start with SELECT , even though the real starting point is the data source in FROM . That ordering never felt natural to us.
So rather than bolt SQL onto something it wasn't designed for, we decided to create something purpose-built: a small, clear language shaped by the way you actually think about events.
... continue reading