Why We're Ditching Cassandra

We're ripping out the database engine that powers our entire platform, and replacing it with something that would've made me laugh a year ago.

We are currently swapping our backend database. It's one of those "one step forward, two steps back" type of changes that normally would be completely out of the question. The coding is no longer the hard part - AI removed that from the equation. What's hard now is making sure the switch leaves the application working exactly the way it did. I'll post more on how we are testing that later.

The backend we use today is Cassandra, an eventually-consistent "big data" store, and its biggest strength is replicating data across machines in a datacenter, and across datacenters entirely. The tradeoffs: no SQL joins, no real ability to query on anything but the primary key. There are indexes, but they're discouraged and limited. I made this choice years ago after a production SQL Server hard disk failure left some real scar tissue. I swore I wouldn't touch SQL Server again if I had a choice.

The destination database is PostgreSQL. We don't need most of the querying power Postgres offers; that's just a bonus. What we get instead is real simplicity: no more query-specific duplicate tables, no more permanent index tables just to get basic business-app functionality out of Cassandra. This move is parity-first. Same behavior, different backend. Baby steps.

So why not just keep Cassandra? One word: memory. Cassandra's own hardware documentation requires a minimum of 8GB of RAM. Most real-world tuning guides push that closer to 16GB or higher once you're running anything meaningful. Postgres, by contrast, can run comfortably on a fraction of that. That gap matters a lot when RAM is the resource your AI agents are competing for on the same box. The original Toodlebox functionality, no-code mobile forms and workflows, is going to take a back seat to agent hosting. So we're reshaping the environment to give the agents the memory they need to function.

It's a strange kind of migration: not chasing new features, just making room. But that tradeoff, giving up a database built for scale in order to make space for something that needs to run efficiently on small, local hardware, is actually a preview of a bigger architectural shift we're making. More on that soon.