The true cost of a cloud copy of your warehouse data, and the cheaper shape

When a logistics company decides to centralize its warehouse data, the moving of the data gets all the attention. It is the visible part: the export jobs, the network, the schedule. It is not where the money goes. Most of the cost of a central copy is what you pay for it to sit there, month after month, waiting to be read.

So it is worth being clear about the shape of the bill before choosing a design, because two designs that produce the same reports can differ in cost by a large multiple.

The expensive shape

The conventional design lifts everything into a cloud relational database (a database engine like the one already running the warehouse, only rented by the hour). It is familiar, the reporting tools connect to it, and it is the first thing a cloud vendor suggests.

Three things make it expensive.

• A relational database engine is priced for transactions, not for holding data. You pay for processing power capable of running a warehouse, twenty-four hours a day, to answer reports that run a few times a day.
• It is sized for peak. To be safe on the busiest day, the rented server is sized for the busiest day and billed for it every day.
• Each site's data adds to the same engine, so the rented server grows with every warehouse you add, and licensing often grows with it.

The result is a central copy that pays for a database engine, per site, every month, forever, for data whose main job is to be summed once a week.

The cheaper shape

The alternative changes what the central copy is, not what it contains. Instead of a relational engine, the central store is low-cost document storage: a store that holds rows cheaply and charges mostly for the space they occupy. It is priced for holding data, which is what a reporting copy does nearly all the time.

The ratio matters more than any particular number. Storage of this kind costs a small fraction of a comparably sized relational database, and it carries no per-site engine license. Adding a site adds storage in proportion to that site's data, and nothing else.

Reports still run. Your reporting tools read from the document store, and for the reports a logistics company actually needs, daily throughput, open orders, inventory by site, exceptions, the store is entirely adequate. We do not claim it is faster than a relational engine; we claim it is cheap to keep, which is the dimension that dominates the bill.

Send changes, not copies

The second cost is moving the data, and here too the shape matters. The conventional design exports each site's tables every night and reloads them centrally. Every night, the whole table, over the wire, whether or not it changed.

The design we use sends only what changed. A small service at each site watches the chosen tables and sends added, changed or deleted rows outward, compressed and encrypted, after a single initial copy. A site whose tables hold years of history but change only a little each hour sends only that little. The volume over the wire tracks activity at the site, not the size of its history.

That volume is small enough to travel over the site's ordinary internet connection. No dedicated line, no private circuit into the cloud, no monthly cost per site for the link. Sites with high-latency or spotty connections are handled, because the service queues changes on site when the link drops and resumes when it returns.

Your account, your rates

The central store can run inside your own cloud account. That means whatever discounts you have already negotiated with your cloud vendor apply to it, and there is no hosting markup layered on top by us. It also means the data never leaves your control.

Putting the shapes side by side: the expensive design pays for a peak-sized relational engine that grows with every site, forever, plus nightly full exports over links sized for them. The cheaper design pays for storage in proportion to data held, transfer in proportion to activity, and an ordinary internet link the site already has. The reports come out the same.

What the cheap shape does not do

It does not replace the warehouse database, and it is not meant to. The warehouse system keeps running on its own server, untouched. It is not a live operational copy either; the central store is current to within a couple of minutes, which is right for reporting and wrong for running a floor.

And it is not free of effort. Each site needs its own setup, driven by a person, and adding tables later is a change someone makes. The cost that disappears is the recurring one, the engine that sits there running, which is the cost that was never worth paying for reports.

Most of the price of a central copy is not the moving; it is what you pay for the data to sit there.

redfly builds this cheaper shape with logistics companies as design partners, one site first, on a subscription that includes the architecture review.