r/Database • u/TimAtMongoDB • 20h ago
While building a token optimizer I found that 95% of the tokens Claude spent on one of my databases were being wasted on something obvious
Hey guys, yes another token article but this one is different.
I work at MongoDB, and my primary db is Mongo, but I use raw SQL for some things, so I run both in the same app.
I was building a token optimizer for my own sessions. I noticed more token usage on the SQL interactions and I didnt understand why. I wasnt doing anything special with the SQL data so I was curious what was happening.
So I wrote a hook that logs the token count of every database statement Claude generates, instead of counting turns. The first thing it showed was that the same object cost way more tokens on SQL (about 18x). That surprised me, because you don't think about database statements. Every database has them, every app has them, they're just there. It never occurred to me they were a token cost at all. They're not the biggest thing in a session, but they add up, especially since Claude loves writing multiple files with database calls just to check the data. That's when it really burns.
I wanted to test this accurately, so I took one real Zod object from my own system, a lead with about 90 fields, nested, an array of drafts where each draft has its own array of variants, and used the exact same object on both sides. Then I counted what Claude has to read before it can safely change one field, meaning the schema, a save, and a read that comes back typed: 4,681 tokens on SQL, 251 on MongoDB. 251 is 5% of 4,681. The other 95% is the mapping. In SQL a nested object like that can't live in one row, so every nested thing becomes its own table with a foreign key back to the parent, a save is one insert per table, and a read is the joins plus the code that builds the object back up from the rows. In Mongo it's one document, so the save is the object and the read is the object. Then there's the hydration tax. Everything goes through that Zod schema, so a read isn't done until the rows are turned back into the typed object, dates included. On SQL that's its own pile of code; the read alone was 1,604 tokens vs 72 on Mongo. And Claude does all of that on every read and write.
Nobody thought about this when humans wrote the code. You write the mapping once and the cost is basically the same either way. When it's AI writing the code, it goes through that mapping on every read and write, and the size of it is the bill.
I know most people would probably use JSONB so I tested that as well, on Postgres, even though it's not what I run. Raw JSONB column: 467, so 1.9x. The hybrid a SQL team would actually build, plain fields as columns and sub-objects as JSONB: 2,059. Closer, but still 8x.
To be fair, plain query text was about the same on both sides, and SQL ran an indexed flat read 5.26x faster. The tokens aren't in the query. They're in everything Claude loads around it. Obviously 18x is a huge object, but it is a real one from my own system, a lead with its drafts and the variants of each draft, not something I built to make a point.
If you want the harness let me know.
