Compute vs Storage Cost Allocation in Separated Architecture Databases

Compute and storage used to fail together. In a separated architecture database, they fail, scale, and cost money on entirely different schedules, and that split changes where a company's spend actually accumulates. This piece walks through each cost layer on its own terms, so a bill stops looking like a black box and starts looking like a set of decisions someone made about tiers, caches, and idle time.

Object storage: why the per-GB headline price is almost never what you pay

Start with the number vendors put on the landing page. S3 Standard in us-east-1 runs $0.023 per GB-month, so a terabyte costs somewhere around $23.55 a month just to sit there. That figure is the floor, not the bill.

It excludes requests, retrieval fees, data transfer, replication, and the operational overhead of managing lifecycle rules across buckets. The gap between the sticker price and the invoice usually comes down to one thing: egress. Pulling data out to the internet costs $0.09/GB for the first 10 TB a month, drops to $0.085/GB for the next 40 TB, and $0.07/GB after that (us-east-1 pricing). Teams spend weeks picking the right storage class and then quietly rack up more in transfer fees than they saved.

Tier spread is where the real money hides. S3 Standard at $0.023/GB is roughly 23 times more expensive than Deep Archive at $0.00099/GB. Most bloated storage bills aren't caused by S3 being pricey, they're caused by cold data sitting in a warm tier because nobody moved it. Azure's Blob tiers tell the same story from a different angle: Hot runs $0.018 to $0.023/GB, Cool $0.010 to $0.013/GB, Cold $0.0036 to $0.004/GB, and Archive at a substantially lower rate (figures reflecting mid-2026 pricing). But retrieval fees flip that math around fast: Cool costs $0.01/GB to pull back, Cold costs $0.03/GB, and Archive can run $0.02 to $0.10/GB. Park data in Archive and then query it weekly, and the retrieval fees eat the storage savings alive.

In a separated architecture, object storage is always on and always accumulating, so misclassifying data temperature is a recurring cost, not a one-time slip. It's a tax that renews every month. Columnar compression pushes back on this in a meaningful way: high compression ratios mean 10 TB of raw data can be stored in object storage as a small fraction of that size. That compression ratio can do more for the storage bill than any tiering decision.

Object storage spend follows data volume, tier assignment, and egress pattern. It does not care how often a query runs. That cost lives somewhere else.

The cache and NVMe tier: what you're buying when you pay for speed

Queries in a separated architecture rarely touch object storage directly. A cache layer, sitting in memory or on local NVMe, intercepts the hot reads and spreads the cost of hitting object storage across many queries instead of paying that toll every time. That's the whole point of the tier: it decouples speed from cost.

Sizing that cache is a real engineering decision with real financial consequences. A hybrid deployment guide from Severalnines recommends sizing the cache disk to 20 to 30% of the working set, and that number determines how often a query falls through to S3 and eats a retrieval fee. Undersize it, and every miss becomes a network round trip instead of a local disk read.

Why does the miss cost so much more than the hit? Because the underlying engine expects a storage-class read speed on the order of gigabytes per second. When a query misses cache and lands on S3 instead, latency comes from the network rather than the CPU, because the request now depends on network transfer instead of local processing. Latency goes up. Cost goes up. Both move in the wrong direction at the same time, which is exactly the failure mode the cache tier exists to prevent.

What does the tier actually cost, though? Depends who's running it.

• Self-managed: NVMe provisioning is a fixed infrastructure cost. It's there whether queries hit it constantly or barely at all, at any level.
• Managed services: the cache tier usually gets folded into compute pricing, so figuring out what fraction of that bill buys cache versus CPU stays murky unless the vendor spells it out.

In hybrid setups, network bandwidth acts as a stand-in for cache capacity. A 1 Gbps link bottlenecks a hybrid deployment almost immediately, and an undersized network behaves like a missing cache: every read that should've stayed local turns into an S3 round trip with an egress charge attached.

The way to think about this tier: cache spend is a bet on repetition. If the working set fits, cost stays flat and latency stays flat. If it doesn't, every miss gets billed at object storage retrieval rates, and that's a cost curve that only gets worse as the dataset grows past what the cache can hold.

Stateless compute: how consumption-based pricing changes the cost of doing work

Fully separated compute nodes carry only CPU and memory. No persistent disk, no replication state to drag along, which means they can spin up, scale out, or shut down without a migration step slowing things down. That statelessness is the mechanism that makes the next part possible.

It also flips the usual cost logic on its head. Storage cost tracks data volume. Compute cost tracks time-on and size, full stop, with data volume mostly out of the equation. That's the structural inversion separated architectures introduce, and it changes how a team should think about optimization: shrinking storage and shrinking compute are two entirely separate projects now.

Billing model matters enormously here, maybe more than any other lever in this piece. Per-minute or per-hour compute billing charges for capacity reserved, so a workload full of small, frequent queries doesn't get penalized just for being curious. Per-query or per-credit models charge for each question asked, which sounds fair until dashboards, exploratory analysts, and automated agents start racking up thousands of small charges that add up to a number nobody budgeted for.

Benchmark numbers make the gap concrete. On TPC-H at scale factor 10, a fully separated engine completed the workload in 2.9 seconds for $0.009 in compute cost. A large warehouse configuration from a competing cloud data warehouse ran the same workload in 15.9 seconds for $0.143, and its 4X-Large tier took 14.7 seconds for $2.121. Other platforms landed anywhere from $0.087 to $2.714, with one query engine taking 26.2 seconds for $0.163 and a serverless warehouse taking 30.7 seconds for $0.436. At the extreme end, the cost gap between platforms widens sharply as data volume grows. The gap between cost and performance doesn't stay flat as data grows, it widens.

Splitting compute from compute, not just compute from storage, produces a lot of the actual savings. A pattern that reached general availability in January 2025 lets multiple workload types (ETL jobs, read-heavy API traffic, human analysts running ad hoc queries) share the same underlying data without sharing a compute pool. Each group gets sized on its own terms. One team, ABTasty.com, reported a job that used to take 8 hours dropping to under 30 minutes once workloads were split this way.

A few smaller levers stack on top of that. Matching replica count to actual availability requirements, rather than defaulting to the highest setting, avoids paying for redundancy that a workload doesn't need. And a scaling approach where new replicas come online before old ones get removed avoids the capacity gap that would otherwise force a team to over-provision just to survive the moment of a scale-up event.

Compute cost in a separated architecture comes down to how precisely each workload gets sized on its own. The win isn't cheaper compute in the abstract, it's not having to provision every workload for the busiest one in the building.

Metadata coordination: the layer that rarely appears on architecture diagrams but always appears on the bill

A coordination layer sits underneath object storage and compute that almost nobody draws on their architecture diagram, and it shows up on every bill whether it's itemized or not. In ClickHouse's design, that job falls to Keeper (or ZooKeeper in older setups), the synchronization layer that makes stateless compute nodes actually workable.

A component introduced in July 2025, SharedCatalog, maintains one versioned global state that every compute node can read. Each node just tracks the last version it applied and fetches the newest one on startup. That's a tidy design, and it's precisely what makes nodes disposable in a way self-managed setups usually can't match.

Self-managed Keeper is a different animal. It's a cluster someone has to run: dedicated compute, a quorum to provision correctly, and latency requirements tight enough that spanning that quorum across a slow WAN link risks pushing the whole cluster into read-only mode if the link degrades.

There's a subtler cost hiding in open-source deployments too. Even when the bulk of the data lives in S3, file metadata for each part still gets written to local disk on the node. For datasets with a large number of small parts, local disk usage keeps climbing no matter how much of the actual data sits in cheap object storage. So the architecture looks separated on the diagram and isn't quite separated on the disk.

A staged object lifecycle, added alongside a newer storage engine, tracks each object's state explicitly instead of tying deletion to whether a node happens to be alive at the moment. That fixes a fragility in older designs where compute-compute separation could cause inconsistency when a node happened to be down at the wrong moment. It's invisible in day-to-day operation, but it matters directly for cost: orphaned objects sitting in S3 that nobody's cleaning up are a real, quiet billing leak in systems that don't handle this carefully.

None of this is a large line item on its own. But it's a fixed floor. Managed services fold it into the service fee, so it disappears from view. Self-managed deployments carry it as its own infrastructure commitment, one that doesn't shrink just because query volume drops for a quarter. Before signing anything, it's worth asking: where does Keeper live, who runs it, and does the system clean up orphaned objects on its own?

Self-managed vs. managed: where the cost layers land differently

Run ClickHouse's ReplicatedMergeTree on S3 without a managed layer, and all four cost centers, object storage, cache hardware, compute instances, and the Keeper cluster, become separate line items with separate failure modes, and someone on staff owns every one of them.

The replication behavior in open-source ReplicatedMergeTree on S3 deserves specific attention here. By default, each replica downloads data from the writing node over the network and then uploads its own separate copy to a different S3 path. Running multiple replicas means each one uploads its own separate copy to S3, multiplying storage consumption and network traffic in ways that quickly become redundant. Approaches exist to reduce this redundancy, but they come with their own limitations that teams should evaluate carefully before relying on them in production.

The infrastructure math for self-managed setups is fairly predictable: a cluster sized for a large event dataset can carry meaningful on-demand compute costs each month. Engineering time is absent from that invoice, and that cost is real and recurring: something in the range of a quarter to half of a full-time engineer's attention per cluster, just for maintenance, upgrades, and the occasional 2am incident.

Managed ClickHouse Cloud bills storage and compute separately, but bundles the cache mesh, Keeper, and metadata coordination into the package. The invoice reads simpler even though the underlying cost drivers haven't gone anywhere. A startup running intermittent queries costs around $67 a month on the Basic tier, while a production analytics team pushing terabytes through daily runs somewhere in the $500 to $1,500 range on the Scale tier.

Egress adds a wrinkle to the managed story too. ClickHouse Cloud charges egress fees running $0.0312 to $0.162 per GB depending on region. A team moving 100 GB a month out of AWS us-east-1 pays an extra $11.50 for that alone, small on its own, but a real factor once someone's modeling a migration and not just a monthly bill.

Managed database storage typically runs $0.115 to $0.170 per GB per month, 5 to 15 times more expensive than object storage at $0.023/GB, and that gap explains why separation matters architecturally, not just operationally. Managed database storage typically runs $0.115 to $0.170 per GB per month, 5 to 15 times more expensive than object storage at $0.023/GB. Separated architecture exists precisely so the expensive tier (compute, and the storage tightly bound to it) can shrink while the cheap tier absorbs the bulk of the data.

SharedMergeTree, the engine behind that fully separated behavior, is proprietary. It's available through managed offerings, ClickHouse Inc.'s own Cloud product and Alibaba Cloud's ApsaraDB for ClickHouse Enterprise Edition, and there's no path to running it in a self-hosted open-source environment. Open-source alternatives exist (projects built around non-replicated MergeTree on s3_plain_rewritable, for instance), but they carry real limitations around write paths and production readiness that a team should weigh carefully before betting a system on them.

A middle path reached general availability in 2025: a bring-your-own-cloud option for AWS, where the control plane stays managed but the data lives in the customer's own VPC and S3 bucket. That shifts data residency and some egress costs back onto the customer while keeping most of the operational benefits of a managed service. It comes with a smaller feature set than the fully managed offering, so it's a genuine tradeoff, not a strict upgrade.

Reasoning About Cost Allocation Across Layers

A single slow, expensive query might trace back to a cache miss forcing an object storage retrieval, heavy compute from an aggregation, metadata coordination getting hammered by concurrent DDL, or an... A single slow, expensive query might trace back to a cache miss forcing an object storage retrieval, heavy compute from an aggregation, metadata coordination getting hammered by concurrent DDL, or an export racking up egress. The invoice just shows a total. It doesn't decompose any of that for anyone.

So how does an engineer reason about this without four dashboards and a guess? Start by matching the workload shape to whichever layer dominates its cost:

• High data volume, low query frequency: object storage tier assignment is the main lever. Compression ratio and how well data gets classified by temperature drive the cost here.
• High query volume against a stable working set: cache hit rate drives the number. If the hot data fits in the cache tier, object storage retrieval cost approaches close to zero.
• Mixed read and write, concurrent ETL alongside analytics: compute-compute separation is the lever. Sizing each workload group on its own terms, instead of provisioning everything for the busiest hour, is what keeps the bill from ballooning.

One might argue the bill should just show this breakdown directly. Maybe someday it will. Until then, the discipline is the same either way: name the layer, name the driver behind it, and check whether the workload's actual shape matches the pricing model it's sitting under. A dashboard-heavy team on a per-query billing model and a batch-heavy team on per-hour compute are both going to look normal on paper, right up until the pattern shifts and the bill stops making sense. Knowing which layer moved means fixing the actual problem instead of re-tiering data that was never the issue.