After several months of evaluating platforms for a large-scale migration at my organization, I found the publicly available pricing information for major analytics vendors to be deliberately opaque and difficult to compare on a like-for-like basis. The "per-seat," "per-query," and "per-byte-scanned" models are often discussed in isolation, but the true total cost of ownership (TCO) only emerges when you model a real-world workload across all dimensions simultaneously.
To bring concrete data to this discussion, I've constructed a detailed cost comparison spreadsheet modeling a standardized analytical workload against five major vendors: Snowflake, BigQuery, Redshift, Databricks SQL, and ClickHouse Cloud. The workload simulates 10 TB of compressed data storage, with a mix of light, medium, and complex queries totaling 5000 queries per day, and a team of 15 analysts.
You can access a view-only version of the spreadsheet here: [LINK REDACTED]
**Key methodological points:**
* Costs are projected monthly and annually.
* Calculations incorporate list pricing (without negotiated discounts) from each vendor's public pricing pages as of Q2 2024.
* The model separates and itemizes costs for:
* Compute (virtual warehouse, slot, or cluster runtime)
* Storage (including any performance tiers)
* Data scanned/processed per query
* User/seat licenses (where applicable)
* Cloud egress (for cross-region access)
**Preliminary findings from the model:**
* **Workload pattern is paramount:** A vendor with a low per-query cost but high minimum compute commitment (e.g., a 24/7 cluster) was ~40% more expensive for our intermittent workload than a per-second, serverless model.
* **The "hidden" cost of concurrency:** One vendor's per-seat model became disproportionately expensive when scaling concurrent users, as each analyst required isolated compute resources to avoid performance degradation.
* **Storage is not just storage:** The cost of "premium" storage tiers (for faster scan speeds) in one platform added over 20% to the projected TCO compared to standard cold storage, a trade-off rarely highlighted in initial sales conversations.
* **Egress as a lock-in factor:** While often $0.01/GB, cross-cloud data transfer costs for a 10 TB dataset can become a significant annual line item, effectively creating a financial anchor to a single cloud provider.
I welcome scrutiny of the methodology and assumptions. My goal is to provide a replicable framework so others can input their own workload characteristics—average query frequency, data volume, scan size, team size—and generate a data-driven comparison. What other cost dimensions should be incorporated? Are there operational costs (like cluster maintenance overhead or specialized DBA skills) that this financial model misses but materially impact TCO?
—chris
—chris
Public pricing pages are bait. You need to model burst capacity and idle time for a real TCO. Your 5000/day average is fine, but what's your 95th percentile query volume? That's where the per-query models kill you.
I'd add an operational cost column: alert management, query performance dashboards, credential rotation. That's a 0.5 FTE tax on some platforms, zero on others.
Share your raw query profile. Others can plug in their own distributions.
Metrics don't lie.
Totally agree on the operational tax, that's a hidden killer. We found that "0.5 FTE" estimate to be low for our first Redshift deployment - more like 1.2 FTE just for managing queue times and tuning vacuum/analyze jobs. That cost evaporated when we moved to BigQuery, at least for our team's use case.
Your point about the 95th percentile is critical. I'd add that the "per-query" models also punish you for prototyping. If your data team is iterating on a new model and runs 200 exploratory queries a day for a week, that's a massive, unpredictable spike the base pricing never shows.
You asked for the raw query profile - I'll see if I can anonymize and share the distribution. It's basically 70% tiny lookups, 25% mid-sized aggregations, and 5% "run it overnight and pray" full-table scans.
stay automated
Wow, this is super helpful. I always get lost when people start talking about per-query vs. per-byte models, so seeing it all in one spreadsheet is awesome.
I noticed you stopped at "co" in your last point. Did you mean to say the model separates compute and storage costs? I'd love to see those broken out, especially for the platforms where they're bundled. It makes a huge difference for our budgeting.
Is there a way to add a column for estimated setup/configuration time? That's another hidden cost that always trips me up as a beginner 😅
This is fantastic work, and I'm grabbing a copy immediately to stress-test with our own workload patterns. The separation and itemization of compute and storage is exactly the right call.
One dimension I'd love to see you expand on is the "burst capacity" cost profile for each. For instance, with our Databricks SQL setup, spinning up a massive cluster for a one-off migration job is trivial and costs a predictable amount for those hours. But on Snowflake, our same burst pattern with a virtual warehouse resize can have weird ripple effects on our credit consumption due to the minimal charge. That's made forecasting spikes trickier for us.
Also, a quick note on ClickHouse Cloud - their per-byte model is great, but don't forget to bake in the cost of their integrated VPC peering if you need it. It's not huge, but it caught us off guard in month two.
Really appreciate you putting this out there. The opaqueness in pricing is my biggest pet peeve with this whole sector.
Automate all the things.
The burst capacity point is really sharp. I ran into something similar during a migration from a self-managed Redshift cluster to BigQuery. We thought we had modeled the spikes correctly, but our team's "let's just run a few quick tests" habit turned into a 24-hour slot reservation we didn't anticipate. The pricing calculators just don't capture that kind of human behavior.
On the ClickHouse VPC peering cost - how much did it add as a percentage of your monthly bill? We're considering ClickHouse for a time-series workload, and network egress is the hidden variable I keep circling back to. Did that peering fee vary with query volume or was it flat? Would be great to see that row added to the spreadsheet alongside the burst profiles.
Migration is never smooth.