One of the most interesting parts of building CamusDB is the query optimizer. It might also be one of the most complex pieces of machinery in the whole database.

At first, a query optimizer sounds simple: receive a SQL query and decide how to run it. But the more features a database supports, the harder that decision becomes. A query can use a table scan, an index lookup, an index range scan, a hash join, a merge join, a nested loop join, a sort, an aggregate, a derived table, or a subquery. Each option can be correct, but not every option is fast.

The optimizer's job is to choose a good plan before the query runs.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

— Antoine de Saint-Exupéry

For many years I worked with Google Spanner, and somewhere along the way I fell in love with distributed SQL databases.

That may sound a little too dramatic for a database, but honestly, it is true.

In the video game industry, databases are not just boring infrastructure sitting in the background. They are a critical part of the player experience. Games need to handle spikes, global traffic, competitive systems, economies, inventories, matchmaking, leaderboards, live events, rewards, and a lot of things that must work correctly even when thousands or millions of players are active.

That is where distributed SQL really clicked for me.

Strong consistency matters. Scalability matters. Being able to reason about your data without constantly adding workarounds, queues, caches, compensating jobs, or manual repair scripts matters a lot. Spanner showed me that a database could solve many of these problems at the infrastructure level instead of forcing every backend team to reinvent the same patterns over and over again.

At some point, I started asking myself: what would it look like to build something like this myself?

Not because the world needs yet another database just for the sake of it, but because I wanted to explore the architecture deeply. I wanted to understand the tradeoffs, the hard parts, the abstractions, and the places where I could experiment with ideas that I think are useful.

That is how CamusDB started.