My database costs more than everything else combined. Here's what I found.

Last week I sat down to cut my AWS bill. I was sure I'd find something dumb. A server left running over a weekend. Some orphaned storage I forgot to delete. Everybody has one of those stories.

I opened the cost breakdown, and there it was. One line, towering over the rest. DynamoDB, my database, was about 70% of the whole bill. Compute, the thing I'd always assumed was the expensive part, sat near the bottom like an afterthought.

I'd been worrying about the wrong thing for months.

So I went hunting for the mistake. And this is the part that got under my skin: there wasn't one.

Let me explain how TechGenie is built, because the cost lives inside the design.

It's multi-tenant. A bunch of businesses use it, and their data has to stay completely separate. In healthcare and finance that isn't a preference, it's the law. So I built it carefully. I have separate tables for each part of the product. Client profiles in one. Users in another. Employees, conversation data, chat logs, callback requests, live agent sessions, each in their own table. Inside every table, every single record carries a client ID, and nothing gets read or written without it. One customer can never see another's data. Ever.

If you know DynamoDB, you know this is the textbook approach. You don't give every customer their own tables. You separate by feature, isolate by key. I followed the playbook.

And the playbook is what's costing me money.

I stopped looking for a villain and started reading the bill like a story. It told me three things.

The data keeps growing because the business keeps growing. Every new customer adds records to every table. That cost climbs as I sign people up, which honestly is the kind of problem I want to have.

But the real weight is the calls. We handle over a million interactions a month, and not one of them is a single database hit. A person sends one message and behind it the system reads their profile, checks the user, writes to the log, maybe files a callback, updates the session. One message becomes five or six trips to the database. Multiply that by a million. The data sitting still is cheap. It's the data moving that bleeds me dry.

And because everything is split by feature, one click can touch four tables at once. That's the price of keeping it clean and auditable. I'd make the same call again. But clean isn't free.

Here's where I actually am: I haven't fixed it.

Not because I'm lazy. Because every easy answer is a door I won't walk through. Delete the unused stuff? It's all in use. Merge the tables? The whole point is that they're separate. Loosen the isolation between customers to save a few dollars? Not a chance. That's the one line the entire product is built on.

So I'm stuck with a real bill and no obvious mistake to blame, and I've decided to just say that out loud instead of pretending I have it solved.

I have ideas. Maybe my billing mode doesn't match my traffic. Maybe I'm making calls I could cache. Maybe eight-month-old chat logs don't need to live in an expensive database that answers in milliseconds when nobody's reading them anyway.

But ideas aren't a fix, and I'm not going to dress them up as one.

So I'll ask instead. If you've run a multi-tenant system where the database became the whole bill, and the architecture was actually correct, where did you start? Access patterns? Storage tiers? Something I haven't thought of?

I'll write the follow-up when I've done the work and have real numbers. For now I'm in the messy middle, and I'd rather tell you the truth from here.