The database is the biggest line on your cloud bill: a breakdown

Take a typical cloud bill for a read-heavy application (one that looks up data far more often than it changes it) and sort the lines by size. The application servers are usually near the top. Storage and network are further down. The managed database, the one the cloud vendor runs for you, is almost always the largest single line, and it is the one that has been growing fastest since the day the bill was first paid.

That is not an accident of any one vendor's pricing. It comes from how a managed database is bought, and from what a read-heavy application asks of it.

Where the money goes

Most cloud bills for this kind of application break into four rough buckets. The application servers, which run your code. The managed database, which holds your rows. Storage for files and backups, and the network, which is what you pay to move data out.

The application servers are elastic; you add them when traffic rises and drop them when it falls, and you pay by the hour. Storage is cheap per unit and grows slowly. Network charges track how much data leaves, which for most business applications is modest.

The database is different from all three. It is bought in fixed tiers, it runs all day and all night, and it is sized for the busiest hour of the month rather than the average one. Industry analysts have called databases the largest and fastest-growing slice of cloud spending, and that matches what we see on the bills we are shown.

Why the database line grows fastest

Three things push the database line up, and none of them slow down on their own.

• Every new user adds reads, and reads are what the database spends most of its capacity on. Permission checks, profile loads, lookups, list pages; each click fires a handful of them.
• The tier is a step, not a slope. When the current size runs hot, the next size costs roughly double, and there is nothing in between.
• Nobody scales down. The upgrade that got you through one busy quarter becomes the new baseline, and the baseline only ever ratchets upward.

Application servers do not behave this way, because you can add and remove them one at a time. The database is one box, and its price moves in jumps.

What the 70% figure means

When we say redfly cuts the bill by about 70%, that figure refers to the database line of the bill, not the whole bill. It is worth being precise, because the two get confused. If the database is half of your cloud spend, a 70% cut to that line is roughly a 35% cut to the total. If it were three quarters, the total would fall by around half.

The mechanism is simple. Around 95% of what an application asks a database to do is reading. If those reads come from a memory cache instead, the database only needs to be sized for the remaining 5% (the writes) plus enough headroom to take reads back if the cache is ever unreachable. That is a much smaller box.

The database is not expensive because it is a database; it is expensive because it is sized for reads it should never have been serving.

What moving reads into memory changes

redfly sits between your application and your database. Reads are served from a memory cache (Redis, a store that keeps data in memory rather than on disk) that redfly keeps in step with the database as rows change. Writes go straight to the database as before. Your codebase carries no cache code and no rules about when to refresh it; that logic lives behind the redfly API.

On the bill, this does three things.

1. The database drops to a tier sized for writes plus fallback.
2. A memory cache line appears. It is smaller than the database line it replaces, because memory for the rows in active use costs less than a database engine sized to answer every read from disk.
3. The peak-day upgrade is no longer forced, because the peak is made of reads, and reads are no longer the database's problem.

What it does not touch

It is equally important to say what this leaves alone. Your application servers cost the same; they still run your code. Storage for files and backups is unchanged; the rows still live in the database. Network charges are unchanged, and if you pay for a database licence separately, that licence remains.

The change is confined to one line, the largest one. Everything else on the bill is what it was, which is also why the change is easy to verify: compare the database line before and after, and the rest of the bill is an unchanged baseline to compare against.

In our experience, the total bill falls in proportion to how much of it the database had been eating, and the peak-season upgrade stops being the reflex.

redfly is one way to make that change without rewriting the application: a cache kept in sync with your database, with the database still the source of truth and still taking every write.