Let's be honest: most analytics vendors talk about "transparent pricing" the same way a used car salesman talks about a "clean history." They'll dazzle you with per-seat licenses, then hit you with compute-hour overages, storage tiers, and egress fees that make your CFO's eye twitch. Per-row pricing sounds beautifully simple—you ingest a row, you pay for a row. But the devil is in the definitions, the compression, the scans, and the fine print.
After watching a dozen clients get burned by "simple" pricing models that metastasize post-contract, I've come to a cynical conclusion: true transparency is less about the pricing model and more about the absence of gotchas. That said, if we're strictly talking about per-row pricing, a couple of contenders emerge, but with massive caveats.
* **Google BigQuery** famously charges for data processed per query (per terabyte scanned), not per row stored. However, their **BigQuery BI Engine** and certain data transfer features can introduce row-based calculations. It's not their primary model, but where it appears, it's relatively straightforward. The opacity comes from the constant need to manage partition filters and clustered columns to avoid scanning your entire wallet.
* **AWS Athena** (Presto under the hood) is pay-per-terabyte-scanned. Again, not strictly per-row, but your cost is directly tied to the number of rows your query touches. The transparency ends the moment you realize a poorly written `SELECT *` on a petabyte table will result in a bill that could fund a small startup. You're one accidental full-table scan away from an unpleasant conversation.
* **Some smaller, newer vendors** like **ClickHouse**-as-a-service providers (e.g., ClickHouse Cloud) often advertise per-row ingestion pricing. This *can* be transparent, but you must grill them on:
* Is the count pre or post compression? (Their compression is stellar, so this is often a win).
* Do "rows scanned" in queries incur additional costs?
* Is there a separate fee for storage compute (a la Snowflake's virtual warehouses)?
* What about replication? Am I paying for each replicated row?
The closest I've seen to actual transparent per-row pricing is from a vendor like **PlanetScale** (for their OLTP-focused offering) or certain time-series databases, but they aren't traditional analytics engines. For analytics, you're often better off with a brutally simple, self-managed columnar database on a VM, where your only "per-row" cost is the disk space it occupies and the compute you rent by the hour. The transparency is that you see the raw AWS bill.
The real answer is that "transparent per-row pricing" is often a siren song. Your cost drivers in analytics are rarely about the row count alone; they're about query patterns, concurrency, and performance expectations. I'd rather have a vendor lay out a clear, itemized bill for compute-seconds, storage-GB-months, and egress-GB, than promise a simple per-row rate that hides the true cost of making those rows useful.
keep it simple
You're right about BigQuery's pricing being more about scans than rows, but I think that's where the real trap is for teams. That "straightforward" per-terabyte scanned model assumes your data engineers are perfect and your analysts never write a wildcard SELECT *.
For every client I've seen get a predictable bill from BigQuery, there are three who get a shock because someone in marketing ran an unbounded query across six months of granular event data. The transparency is there in the pricing sheet, sure, but the practical opacity is in your own team's query discipline.
You've nailed the core problem. That pricing sheet transparency is useless without operational control. BigQuery's model essentially taxes your team's worst habits, and you can't fix human nature with a pricing page.
I've had to implement mandatory query review gates and automated cost alerts for every client using scan-based pricing. Without that, you're just hoping your finance team never learns SQL. The vendor provides the meter, but you build the guardrails, and that's a hidden cost they never mention.
Some platforms are starting to offer per-query pricing caps or hard stops, which at least turns a surprise into a failed job. But that's a feature, not a given.
Been there, migrated that