Choosing an analytics platform by the constraint that binds

Every vendor in this space presents the same slide: one platform for analytics, machine learning and streaming, with governance included. The slides are indistinguishable, which tells you the differentiation is no longer in the feature list.

What actually differs is the cost model, the governance boundary and the workload each platform is genuinely good at. And underneath all of it, something structural has changed that matters more than the vendor choice.

Open table formats changed the negotiation

Historically, loading data into a warehouse meant loading it into that warehouse's proprietary storage. Leaving meant exporting everything, which is why migrations were rare and pricing power sat with the vendor.

Open table formats, chiefly Iceberg and Delta Lake, put table semantics on top of files in your own object storage. You get the things that made a warehouse worth using, transactions, schema evolution, time travel and efficient updates, on data you control, in a format multiple engines can read.

The consequence is that storage and compute become genuinely separable. Your data sits in your bucket, and the query engine is a choice you can revisit. Every major platform now supports reading and increasingly writing these formats, some more completely than others, and the interoperability between them is improving but is not yet frictionless.

The practical advice: land your data in an open format in your own storage as the default, and treat the engine as replaceable. That single decision preserves optionality worth more than any feature comparison, and it is the same instinct as keeping the native billing export alongside a normalised one in FOCUS and comparing two clouds.

What actually differs between the options

Snowflake is a warehouse first, and its strength is that it is genuinely easy to operate. Compute is separated into warehouses that you size and that suspend when idle, so concurrency between teams is a configuration rather than a tuning exercise. It suits SQL-centric analytics with many concurrent business users. The cost model is credits per compute-second, which is comprehensible and gets expensive when a warehouse is left running or sized generously.

Databricks grew from Spark and is a processing platform that added a warehouse. Its strength is heterogeneous work: large-scale transformation, machine learning, streaming and analytics in one place, with notebooks as a first-class interface. It suits teams doing engineering and data science rather than only reporting. The cost model is compute plus a platform charge per unit of work, and the cluster configuration is a lever you must actually use.

The cloud-native warehouses are the option teams underrate. If you are on one cloud, the native warehouse integrates with identity, networking, billing and the rest of the platform with no additional vendor. Its cost model tends to be per byte scanned or per slot, which is excellent when queries are well-written and partitioned, and is the origin of the most spectacular cost failures when they are not, as described in BigQuery bills that triple overnight.

Query engines over your own storage, such as Trino or DuckDB for smaller scales, are worth knowing about. They are a legitimate answer for a team that wants SQL over open formats without a platform contract.

The cost model is the thing you will live with

Every platform is affordable when used carefully and expensive when not, but they fail differently, and knowing the failure mode is more useful than comparing list prices.

Per byte scanned fails through unpartitioned tables and SELECT * in a dashboard that refreshes every minute. The controls are partitioning, clustering, required filters and per-query limits.

Per compute-second fails through idle warehouses and oversized clusters. The controls are auto-suspend with a short timeout, right-sized warehouses per workload, and separating the dashboard workload from the transformation workload so one does not force the other to scale.

Per unit of work fails through inefficient jobs that run longer than they should, which is a tuning problem rather than a configuration one.

In all three, the largest single cost driver is usually the same and rarely discussed: dashboards refreshing more often than anyone looks at them, and transformation models rebuilding more often than the data changes. Fix the schedule before you tune the engine, which is the point made in orchestration and transformation.

Whichever you choose, attribute cost to teams from the start. The platforms all support tagging queries or separating compute by team, and without that you have a single large line nobody owns, which is the problem described in the number that matters is cost per customer.

Governance is where the real lock-in lives

The catalogue, the access control model and the lineage are harder to move than the data.

Ask concrete questions rather than accepting the governance slide. Can you enforce row-level and column-level access for the groups you actually have? Does access control apply when a different engine reads the same files, or only inside this platform? Is lineage captured automatically or does it depend on using their transformation tooling? Where does the metadata live, and can you get it out?

For European buyers, add the residency and access questions: where the control plane runs, who can access data during support, and whether the arrangement fits the transfer analysis in where your data actually sits. This decides the shortlist more often than performance does.

Analytics and machine learning are different workloads

Be honest about the mix, because it points at different answers.

Mostly SQL reporting with many business users favours a warehouse, where concurrency and ease of use dominate and Spark's flexibility is overhead you pay for.

Heavy transformation, semi-structured data, streaming, and model training favours a processing platform, where a warehouse forces you to bolt on a second system anyway.

Both, at scale is what the vendors claim to solve, and they increasingly do, with the honest caveat that each is still better at its origin. Running the warehouse workload on a platform optimised for processing, or vice versa, is where teams end up paying for capability they are not using.

A common and sensible pattern: open table format in object storage, a processing engine for transformation and machine learning, and a warehouse engine for the serving layer that analysts query. Two engines, one copy of the data, which is only possible because of the format decision at the top of this article.

The things people forget

• Small files destroy performance. Streaming ingestion produces thousands of tiny files and query time collapses. Compaction is a maintenance job you must schedule.
• Time travel is storage. Retaining old versions for rollback is genuinely useful and costs money. Set the retention deliberately.
• The semantic layer is a real decision. Where metrics are defined determines whether two dashboards agree.
• Egress on the way out. A migration means moving a large volume of data, and the transfer cost is a real number.
• Concurrency limits bite at quarter end. Everyone runs the same report on the same day.
• Proof of concept on your data, not theirs. Vendor benchmarks use queries chosen to look good. Run your ten most expensive real queries.

What to do this week

Take your current analytics bill and break it into three buckets: scheduled transformation, dashboard refresh, and ad hoc queries by people. Most teams have never done this split, and it usually shows that a large share of spend is dashboards refreshing on a schedule nobody chose. That finding is independent of which platform you are on, and fixing it is cheaper than migrating. We produce that breakdown in the cost phase of a cloud engagement.