Snowflake, Databricks, Data Warehouses, and Data Marts: What Belongs Where?

Product capabilities and regional availability in this article are as of 20 September 2026. INVISOM has no commercial relationship with Snowflake or Databricks.

The question has changed

For most of the last decade, "Snowflake or Databricks?" was a real fork. Snowflake was the SQL data warehouse built for the cloud. Databricks was the Spark-based platform for data engineering and machine learning on open files in your own storage. The choice shaped your file formats, your skills and your architecture.

That fork has largely closed. Over 2024 to 2026 the two platforms converged on almost every axis that used to separate them.

Both now read and write Apache Iceberg v3 tables through open REST catalogs. Snowflake can write directly to tables registered in Databricks' Unity Catalog as a documented, generally available feature. Both run serverless SQL warehousing, both expose large language model functions from SQL, both have governed semantic layers, and both now sell a managed Postgres database for operational applications, after Snowflake acquired Crunchy Data and Databricks acquired Neon in 2025.

The useful question is no longer which platform is better. It is which workloads belong on which engine, and where your business logic and policies should live, because that is where lock-in has moved.

Where real differences remain

Convergence is not sameness. Several differences still matter in practice:

The "center of gravity" row is an INVISOM judgment, not a vendor claim. Both platforms can do all of these things; they differ in where their tooling, ecosystem and typical user base are strongest.

The billing row matters more than it looks. Databricks on classic compute produces two invoices, one from Databricks and one from the cloud provider, often under a separate committed-spend agreement. Total-cost comparisons that count only one of them are common and misleading.

The new lock-in: definitions and policies

If both platforms can read the same tables, what is left to lock you in? Snowflake's own engineers answered that question with unusual candour in July 2026.

In their assessment, sharing the data itself through Iceberg and REST catalogs is mostly solved, and object-level access through catalog-vended credentials is largely solved. But business logic (views, user-defined functions, stored procedures and metric definitions) has no complete, widely adopted standard. Fine-grained access control, meaning row and column security, has no standard mechanism that guarantees consistent enforcement across engines. And audit across multiple engines cannot reliably answer who read what. Their recommendation for sensitive, curated data: store it in Iceberg for future flexibility, but restrict access to a single governed engine.

This reframes the architecture decision. Ask where your definitions and policies live, not where your data lives. The tables are portable. The thousands of views, metrics and security rules built on top of them are not, and they represent most of the accumulated investment in a mature data platform.

The emerging hedge is the semantic layer. Databricks made governed metric definitions in Unity Catalog generally available in April 2026, Snowflake has semantic views, and both vendors participate in the Open Semantic Interchange, an open specification for exchanging semantic models whose first version was finalized in January 2026. It is early, but it is the place to watch.

Warehouses, marts and the semantic layer

The data warehouse and the data mart are old ideas that still matter, though not always in the form they used to take.

In Bill Inmon's model, an integrated enterprise warehouse feeds departmental marts. In Ralph Kimball's model, the warehouse is built incrementally, process by process, and held together by conformed dimensions: shared definitions of customer, product, date and location that every subject area reuses. Both schools agree on the essential point: the value is in consistent, shared definitions.

In 2026, most of what a data mart used to provide is moving into the semantic layer. Metric definitions, business-friendly names and consistent aggregation rules can now be governed as metadata rather than duplicated in physical tables. That leaves physical marts with a narrower but real job:

• Serving performance and concurrency for heavily used BI, where a purpose-built, pre-aggregated structure keeps dashboards fast and predictable.
• Cost isolation and chargeback for a department that needs its own budget line.
• Regulated subsets that should live on one engine with one set of controls, as the Snowflake engineers recommend.
• Data products owned by a domain team, published for others to consume.

Kimball's conformed dimensions turn out to be more important than ever, because they are the part of a data architecture that is genuinely portable between engines.

What belongs where

With both platforms able to do most things, placement should follow workload characteristics and where your team's strengths lie, not vendor messaging.

Three principles keep the result coherent:

1. One owner per dataset. Even when two engines can write to the same Iceberg table, give each curated dataset a single owning engine and catalog for writes and policies. Others read.
2. Definitions in one place. Choose where metrics and conformed dimensions are governed, and treat every other copy as a derivative.
3. Run both only for a reason. Many large enterprises do run both platforms, often for organizational rather than technical reasons. That is workable with open tables, but it doubles the governance surface and should be a deliberate choice.

Do not decide on benchmarks

Vendor benchmarks between these two platforms have a history worth remembering.

In November 2021, Databricks announced an audited TPC-DS 100 TB record and published comparisons suggesting it was far faster and cheaper than Snowflake. Ten days later, Snowflake's co-founders published their own run of the same benchmark, at 3,760 seconds on a 4XL warehouse for about $267, and criticized the comparison. Three days after that, Databricks reported that rerunning Snowflake on the official TPC-DS dataset took 7,276 seconds at best, and noted that Snowflake's pre-built sample dataset had been regenerated after the original announcement.

Same benchmark, same month, three materially different answers. Customer migration stories show the same pattern: each vendor publishes case studies of customers moving from the other and saving substantially. They are workload-specific, not audited, and they point in opposite directions.

The only benchmark that matters is your own workload, with your own data volumes, concurrency and query patterns, priced with every invoice included.

The Gulf view: residency is decided per feature

For organizations in Saudi Arabia and the UAE, regional availability narrows the choice before features do.

Three points stand out as of September 2026:

• Cloud choice can decide platform choice. An enterprise committed to AWS in the UAE currently has Snowflake in-region but not Databricks. On Google Cloud in Dammam, both are available, but Snowflake's hybrid tables and Snowflake Postgres are not offered on Google Cloud at all.
• Saudi hyperscaler regions are arriving. Microsoft has said its Saudi Arabia East region will be available to customers in November 2026, and AWS has announced its Saudi region for December 2026. Platform vendors typically add support after a region launches, so Gulf roadmaps should plan for a re-evaluation during 2027.
• AI features are where data leaves the region. Both platforms are available in-region for storage and SQL. But many of their large language model features rely on cross-region processing. Snowflake documents cross-region inference for its Cortex AI functions, and Microsoft's Azure Databricks feature table marks several AI capabilities in UAE North as available only with cross-geography processing enabled.

The practical consequence: "the platform is available in Dubai or Dammam" is not a residency answer. For data subject to Saudi personal data protection rules or national data classification, covered in our NDMO implementation guide, architecture reviews need to go down to feature level and check how each AI capability routes data before it is enabled.

What to do next

1. Inventory your logic, not just your data. Count the views, functions, metrics and row and column policies on your current platform. That number, not the data volume, is your real switching cost.
2. Adopt Iceberg for new curated datasets where both engines may need access, with a single owning engine and catalog for each.
3. Move metric definitions into a governed semantic layer and keep conformed dimensions as the shared backbone.
4. Rebuild your TCO model with every invoice, including cloud-provider compute for classic Databricks and serverless features on both.
5. Run a bake-off on your own workloads before any platform decision or migration, rather than relying on vendor benchmarks or case studies.
6. In the Gulf, review residency feature by feature, including AI inference routing, and plan to revisit region choices as the Saudi hyperscaler regions come online.

Frequently asked questions

Is Snowflake or Databricks better in 2026?

Neither is better in general. Both now support Apache Iceberg, serverless SQL, AI functions, semantic layers and managed Postgres. Snowflake remains strongest in SQL-first analytics and data sharing; Databricks in data engineering and ML. The right answer depends on your workloads, cloud and skills.

Can Snowflake and Databricks share the same data?

Yes. Both read and write Apache Iceberg tables through REST catalogs, and Snowflake can write to Iceberg tables registered in Databricks Unity Catalog. Business logic, fine-grained security policies and audit still do not transfer cleanly between engines.

Do data marts still make sense?

Yes, but for narrower reasons. Metric consistency is moving into governed semantic layers. Physical marts remain useful for BI serving performance, cost isolation, regulated subsets and domain-owned data products.

Are Snowflake and Databricks available in Saudi Arabia and the UAE?

As of September 2026, Snowflake runs on AWS UAE, Azure UAE North and Google Cloud Dammam; Databricks on Azure UAE North, Azure Qatar and Google Cloud Dammam. Some AI features in these regions rely on cross-region processing, so check residency feature by feature.

Sources and further reading

• Multi-engine lakehouse interoperability, Snowflake Engineering, 28 July 2026.
• Apache Iceberg v3 support generally available, Snowflake, 7 May 2026.
• What's new in Unity Catalog at Data + AI Summit 2026, Databricks, June 2026.
• Set up bidirectional access to Unity Catalog, Snowflake documentation.
• Snowflake Postgres generally available, Snowflake, 24 February 2026.
• Databricks Lakebase is generally available, Databricks, 3 February 2026.
• Redefining semantics in the data layer, Databricks, 2 April 2026.
• Open Semantic Interchange specifications finalized, Snowflake, 27 January 2026.
• Benchmark dispute: Databricks, 2 November 2021; Snowflake, 12 November 2021; Databricks, 15 November 2021.
• Regions: Snowflake; Databricks on AWS; Azure Databricks; Azure Databricks feature availability; Snowflake Cortex cross-region inference.
• Microsoft Saudi Arabia East region announcement, Microsoft, 31 August 2026.
• AWS to launch first cloud infrastructure region in Saudi Arabia in December, Saudi Press Agency, September 2026.
• Enterprise data warehouse bus architecture, Kimball Group.