In a world that's moving faster every day, where software verification is essential to keep up with that pace, building increasingly specialized harnesses, simulators, and test suites has become imperative.

A few weeks ago, we introduced Caraxes, our test suite for simulating extreme scenarios and pushing the database to its limits under all kinds of conditions: node failures, network issues, disk contention, and more.

The results have been extremely valuable, helping us uncover issues in both performance and correctness.

It's similar to putting an F1 car through different configurations in a simulator before those failures happen during a race. It allows us to expose the system to hundreds of hours of testing and exceptional conditions, compressed into just a few hours.

This post is the second part. It tells what the dragon found, what we fixed, and how the database is more robust today.

A player spends forty hours to earn a sword. Another player pays real money for a bundle of skins. A guild saves gold for three weeks to buy a fortress.

None of that is "game data" to the person who did it. It is time, money, and trust. When a backend loses an item, duplicates a currency, or shows two owners for one mount, the player does not read it as a bug. The player reads it as disrespect.

We run game backends on CamusDB today. This post explains why we treat every inventory and every wallet as a small bank account. It also explains why that decision leads to distributed transactions, not away from them.

A database earns your trust on its worst day, not on its best one.

When everything is healthy, almost any database looks correct. You insert rows, you read them back, and the numbers add up. The real question is what happens when a server dies in the middle of a commit, when the network starts losing packets, or when a disk fills up while a transaction is still writing.

Those moments are hard to create by hand. They are also the moments a distributed database exists to survive.

So we built a tool that creates them whenever we want. We named it Caraxes, after a dragon, because its only job is to attack our own cluster while we watch what happens.

Software is starting to work at a different rhythm.

A developer may test one idea at a time, but an AI agent can explore several possible solutions in parallel. One path may try a schema migration. Another may rewrite some data. A third may reproduce a bug using a different sequence of events.

Each path needs a database that feels real, but none of them should be allowed to damage the shared starting point.

This is where database branching becomes more than a convenient development feature. It becomes a practical way to give every experiment a safe place to work.

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.