Your hosting bill is usually a caching problem

A client came to me because their managed-database bill had roughly tripled in a few months while their traffic had barely moved. They assumed they had outgrown the free tier and needed a bigger plan. They had not. They needed to stop asking the database the same questions over and over.

This is one of the most common surprises in a modern web stack, and it is nearly always the same shape.

Where the money goes

Most hosting and database platforms now charge for egress: the volume of data leaving their servers. Every page render that fetches fresh content, every list of products a browser loads, every realtime connection ticking away in the background, that is data leaving the platform, and it is metered.

The problem is that the default way a lot of sites get built, especially quickly or with an AI tool, is to fetch fresh data on every single request. No cache. A page for a product that changes maybe once a month gets rebuilt from a database query on every visit, every crawl, every bot.

In this case the culprits were textbook:

• Pages marked "never cache" that showed data changing at most weekly, so every visitor triggered a full query with several table joins.
• The same query running twice per page, once to build the page's title and description and once for the page itself, because the framework only removes duplicates when caching is on.
• SELECT * everywhere, pulling every column of every row when the page used four of them.
• The homepage firing six or seven separate queries straight from the browser, one per component, on every visit.
• Realtime subscriptions left running on every page, not just the pages that needed them.

None of this is a bug. Everything worked. It was just expensive, invisibly, and it scaled with traffic in exactly the wrong direction.

The fixes are boring and cheap

• Cache things that do not change second to second. A 60-second cache window on a product page is imperceptible to a visitor and collapses hundreds of identical queries into one.
• Put a cache in front of your API. A Cache-Control header lets your hosting CDN answer repeat requests without touching the database.
• Ask for the columns you use. Replace SELECT * with an explicit list. Less data over the wire, every time.
• Move list-fetching to the server. Render the list once, cache the HTML, serve that, instead of every browser querying the database directly.
• Scope realtime to the pages that need it.

We cut that client's egress by roughly half in an afternoon, with no change a visitor could see. The bill followed.

The general rule

If a hosting or database bill is climbing faster than your traffic, the question is almost never "do I need a bigger plan?". It is "how many times am I asking the same question, and could I have remembered the answer?".

If yours is heading the wrong way, we can audit where it is going and usually fix most of it quickly.