Data Platform & Analytics · Chapter 9 of 10
Databricks, Snowflake, and running both
Named in 66% of enterprise postings in a reader-supplied sample, and 30% name both. The question is not which one.
These two dominate enterprise data platform postings by name rather than by category, which is unusual — most job descriptions name capabilities. Understanding what each actually is, and why so many organisations run both, is worth more than a preference.
What genuinely still differs
| Databricks | Snowflake | |
|---|---|---|
| Centre of gravity | Engineers who write code | Analysts who write SQL |
| Native unit | Files in object storage, Delta or Iceberg tables | Tables in a managed service |
| Compute model | Clusters you size and tune, plus serverless | Virtual warehouses that auto-suspend |
| Where it is strongest | ML, streaming, large unstructured transformation | Concurrency, SQL analytics, sharing, ease of operation |
| Where it costs you | Cluster tuning is real work, and idle clusters are real money | Runaway queries are cheap to write and expensive to run |
| Governance | Unity Catalog | Horizon / native RBAC and masking |
| The honest weakness | Complexity — many ways to do the same thing | Escaping SQL for heavy engineering work is less natural |
Why organisations end up with both
- Acquisition. The most common reason, and it is nobody's design.
- Two org units each chose well. The ML team picked Databricks and the finance analytics team picked Snowflake, and both were right for their workload.
- Migration that stalled at 70%. The value was front-loaded and the last 30% was never funded, so both run forever — the same pattern as any migration.
- Deliberate separation of engineering compute from analyst-facing serving, which is a legitimate architecture and not a mistake.
What an interviewer is actually asking
Not which you prefer. They are asking whether you can make two expensive platforms coexist without duplicating the data or the definitions — because the failure mode is two copies of the customer table with two different definitions of active, and every number in the business then depending on which one you queried.
The answer that lands: one storage layer in an open table format, one place where conformed entities are defined, and the two engines reading it rather than each owning a copy. Iceberg and Delta with interoperability make this genuinely possible now, which was not true three years ago. Then be honest that governance across both is the hard part, because each has its own catalogue and they do not reconcile themselves.
What to actually learn
- Pick one and go deep rather than claiming both shallowly, and be explicit about which. Interviewers can tell within two questions.
- Learn the cost model of whichever you pick, because that is where enterprise conversations go. Cluster sizing and auto-termination for Databricks; warehouse sizing, auto-suspend and query cost attribution for Snowflake.
- Understand open table formats — Iceberg and Delta — because they are what makes coexistence possible and they appear in 36% of postings.
- Know the governance surface of your chosen platform, since governance is named in 68% of postings in the same sample.