Snowflake's Databricks comparison, fact-checked claim by claim

On September 3, 2026, Snowflake's engineering blog published a fifteen-minute post titled "Beyond the Benchmark: The Real World Total Cost, Security and Agility of Enterprise Data Platforms". It is a vendor comparison, so nobody expects it to be neutral. But it does something unusual for the genre: it quotes Databricks documentation, with links. That makes it checkable.

So we checked it. Every claim below is a claim the article makes about Databricks. Under each one is what the Databricks docs said on September 6, 2026, with the sentence linked. Where a claim is about an open-source project rather than a product, we went to the repository instead, pinned to a commit. Claims about Snowflake's own product are out of scope; this site tracks Databricks names, not Snowflake ones. The one exception is the article's Apache Polaris commit statistics, because they are offered as the contrast to Unity Catalog's and the same measurement covers both.

Two verdicts per claim. "Accurate?" asks whether the docs say what Snowflake says they say. "Misleading?" asks whether a reader who takes the claim at face value ends up believing something false about Databricks. The two are independent: a claim can be word-for-word true and still mislead, and a claim can be wrong on a detail that changes nothing. The first verdict is a fact check. The second is judgement, and the criteria for it are stated in the box below the ledger, so you can disagree with them.

The scorecard

Compute: the tuning tax

The claim. Databricks requires manual node sizing, driver configuration, and cluster tuning. As evidence, the article quotes a Databricks sentence: "The organization of this article assumes you are using the simple form compute UI", and adds that this is the alleged simple configuration.

The docs. The quote is real. The compute configuration page does say it assumes you are using the simple form compute UI. That page describes classic compute, which you do size yourself.

What the article leaves out is that Databricks also sells compute you do not size. With serverless compute, you run workloads without provisioning any compute resources in your cloud account, and Databricks says this minimizes idle time, and reduces the need to manage compute resources. For SQL, a serverless SQL Warehouse promises that capacity management, patching, upgrades, and performance optimization are all handled by Databricks, and its auto stop default is 10 minutes. On billing, the pricing page says you only pay for the products you use at per second granularity.

The claim. Cluster spin-up and spin-down latencies lead to costly idle time or user cold-start delays.

The docs. True of a classic cluster, and Databricks sells two things to remove it. Pools keep warm instances so that cluster start and auto-scaling times are reduced, at a price the docs state plainly: Databricks does not charge DBUs while instances are idle in the pool, but the cloud provider still bills them. Serverless SQL warehouses go further and promise that they eliminate waiting for infrastructure resources. So the idle-time trade-off the article describes is real, and it is the trade-off the serverless option was built to end.

Verdict. Holds for classic compute. Pools and serverless exist because it does. Misleading by omission, for the same reason.

One small correction. The article calls Photon a "Spark engine". Databricks describes Photon as the Databricks-native vectorized query engine. It runs Spark workloads. It is not Apache Spark.

Verdict. Holds for classic compute. It ignores that the serverless option exists. Misleading by omission: a page about classic compute is made to stand for all Databricks compute.

Openness: UniForm, Delta Lake, and liquid clustering

The claim. UniForm runs asynchronous metadata translation jobs after every write, introducing driver overhead, protocol version constraints, and write latency.

The docs. This is accurate. Databricks triggers metadata generation asynchronously after a Delta Lake write transaction completes, and that process uses the same compute that completed the Delta Lake transaction. To limit the latency, tables with frequent commits might group multiple Delta Lake commits into a single commit to Iceberg metadata. The protocol constraint is real too: the Delta Lake table must have a minimum reader version of 2 and writer version of 7. And the result is one-directional: Iceberg client support is read-only.

The article does not mention that Databricks now also has Unity Catalog managed Iceberg tables, which are native Iceberg tables rather than translated Delta tables. External engines read from and write to Unity Catalog-registered Iceberg tables through the Iceberg REST catalog. UniForm is the bridge for existing Delta tables, not the only Iceberg story.

Verdict. Holds. Not misleading about UniForm itself. It misleads only if read as the whole Iceberg story, because managed Iceberg tables go unmentioned.

The claim. Delta Lake was built Spark first, and other engines need custom connectors or translation layers.

The docs. Databricks says Delta Lake is open source software that extends Parquet data files and that it was developed for tight integration with Structured Streaming, which is a Spark API. So yes, Spark first. But the same page says the transaction log has a well-defined open protocol that can be used by any system to read the log, and the Delta Lake project lists connectors read and write Delta tables from various data processing engines, naming Flink, Hive, Trino, and Athena. Every table format needs a connector per engine. Iceberg does too.

Verdict. Holds, with context. "Needs connectors" describes Iceberg as much as Delta. Partly misleading: the connectors are open source, and the sentence would be as true of Iceberg.

The claim. Liquid clustering forces Delta tables onto writer version 7, so external Delta readers and third-party tools cannot write to or interact with these tables. The article calls this a proprietary engine-level writer requirement, not an open layout standard.

The docs. The version number is right. Tables with Liquid Clustering use Delta writer version 7 and reader version 3, and Delta clients that don't support these protocols cannot read these tables.

The "proprietary" part is where it goes wrong. Clustering is defined in the open Delta protocol, in the Clustered Table section, as a writer feature named clusteredTable. Databricks' own compatibility page explains that writer features require minWriterVersion=7 but don't block reader clients, and that the open source Delta Lake protocol has standardized on table features. Open-source Delta Lake writes clustered tables itself: the feature is available in Delta Lake 3.1.0 and above, and there the tables use Delta writer version 7 and reader version 1. The implementation is in the open-source repo, not behind a Databricks wall: the Spark module carries a ClusteredTableUtils that checks the clusteredTable feature and writes clustered tables from plain Apache Spark.

Note the difference in reader version. Open-source Delta says 1. Databricks says 3. That is because Databricks turns on other features by default when it creates a table, and some of those are reader features. The lock-out the article describes is real for old clients, but it comes from the bundle of defaults, not from clustering.

Verdict. Partly holds. The protocol requirement is real. "Proprietary" is not: the feature is in the open spec and open-source Delta Lake writes it. Misleading, because the false word is the one doing the work.

Openness: the "asymmetric walled garden"

The claim. Databricks lets external engines in through Unity Catalog's Iceberg REST endpoint, but rejects outbound Iceberg REST connections to Snowflake, AWS Glue, or Apache Polaris. Tables from external catalogs are read-only, quoting "Foreign Iceberg tables are read-only in Databricks and have limited platform support."

The docs. The quote is exact and current. A foreign Iceberg table is one managed by a catalog outside Unity Catalog. Databricks uses Lakehouse Federation to retrieve metadata and read the table from object storage, and foreign Iceberg tables are read-only in Databricks and have limited platform support.

One word needs care. "Rejects outbound connections" reads at first as "will not connect", and that is not what the docs say: the same page lists the foreign catalogs Lakehouse Federation connects to: AWS Glue, Hive metastore, or Snowflake Horizon Catalog. Read "outbound" as "outbound writes", though, which is what the surrounding sentences mean, and the claim holds: Databricks connects to Snowflake Horizon and Glue, reads their Iceberg tables, and writes nothing back. The article's own summary table puts it correctly as "read-only access". The sentence overstates; the section does not.

We could not find a Databricks doc for a generic Iceberg REST catalog connection, Polaris included. We also could not find one that says it is unsupported. Absence of a page is not a citation, so we leave that specific point open.

Verdict. Holds on substance: foreign Iceberg catalogs are read-only, so there are no outbound writes. "Rejects connections" overstates, since the read-only connections exist. Not misleading, because the article's summary table states the read-only point correctly.

The claim. Open-source Unity Catalog shares only a name with the Databricks product, and most of its commits come from Databricks employees.

The docs. Databricks' documentation says Unity Catalog is also available as an open-source implementation, and the project's own README describes it as a sandbox project of the LF AI and Data Foundation under an Apache 2.0 licence. Whether the two implementations share code is not something a documentation page will tell you. Whether they share an API is. The open-source project's OpenAPI spec serves its catalogs at the path /api/2.1/unity-catalog/catalogs, and the Databricks REST API reference lists the product's list catalogs endpoint at exactly the same path. Same version prefix, same resource names for catalogs, schemas, tables, volumes, models, credentials, and external locations. "A name and nothing else" is not accurate: a client written against one talks to the other. How much of the code behind that API is shared is a different question, and not one either side documents.

The repos. Commit shares are not in any doc, but they are in the git history, so we measured them. The article's footnote describes its method as commit volume "by contributor corporate domain affiliation", so we used the same proxy: the domain of each commit's author email. We cloned unitycatalog/unitycatalog and apache/polaris at the commits linked, both from the first week of September 2026, and counted every commit on the default branch.

Percentages are of human commits. Two readings follow. For Unity Catalog, a Databricks address is the largest single visible domain, but it is one third of commits, not a majority. The other two thirds are Gmail addresses and hidden addresses, which say nothing about who pays the author. Some of those people may work at Databricks; the repo cannot tell you. "Strip away the Databricks payroll and the community nearly disappears" is not something this data supports, and not something it refutes.

For Polaris, the footnote's numbers do not reproduce from commit addresses at all. Snowflake addresses are on 3.5 percent of human commits, which is close to the 7.6 percent claimed only if you are generous. Dremio addresses are on 2.1 percent, nowhere near 38 percent. The explanation is in the table: the two biggest human domains are Gmail and apache.org, and an apache.org address hides the employer by design. Whatever analysis produced 38 percent mapped people to companies by some means other than their commit address, and the footnote does not say which. A dependency bot, meanwhile, authored almost a third of all Polaris commits, which any "commit volume" figure has to exclude first.

Verdict. "A name and nothing else" does not hold; the two share the REST API. The Unity Catalog "majority" is not supported by the repo, and the Polaris footnote does not reproduce by the method it describes. Neither project's governance is in question: both READMEs say Linux Foundation, Apache 2.0. Misleading on the API claim and on the Polaris figures. The "majority" is unsupported rather than disproven.

Security: RBAC

The claim. Databricks lacks a true RBAC engine, quoting "In Databricks, a role is implemented as a group". Role assumption was introduced in 2026 as a retrofitted feature and requires compute-context switches whenever users scope permissions.

The docs. The quote is exact: in Databricks, a role is implemented as a group. The dates are right too. Role-based access control (RBAC) entered Public Preview on July 22, 2026 and became generally available on August 19, 2026. The behaviour matches the article's description: assuming a role replaces the user's inherited permissions with only the assumed role's permissions for the session, and a user can only act as one role at a time.

The compute-switch claim is where the docs disagree. Users can assume a role through several methods, including the role switcher in the Workspace UI, the CLI, the API, and BI tools. A dedicated-access-mode cluster assigned to a group is one of those methods, not the only one.

The article also says admins must "resolve workspace entitlement overlaps". We looked for that on the RBAC limitations page. It lists unsupported features, group-management limits, and a cap: workspace asset sharing controls can be applied to a maximum of 100 groups by default. Nothing on it is called an entitlement overlap. That does not make the phrase wrong; it makes it undocumented.

Verdict. The quote and the 2026 date hold. "Requires compute-context switches" does not hold as worded. "Entitlement overlaps" is not in the docs. The quote is not misleading. The compute-switch claim is. The overlaps phrase is unsupported. Whether a group with an Assume permission counts as a "true" role is a definition, not a fact.

Security: ABAC and tagging users

The claim. Unity Catalog only permits tags on data objects, not users or principals. Because user tags do not exist, evaluating user attributes means hardcoding group names into custom SQL UDF wrappers. The article asks how you can tag principals in Databricks and answers: you can't.

The docs. On tags, the article is right. Governed tags can be applied to Unity Catalog objects such as tables and catalogs and to workspace objects like dashboards and notebooks. Users are not on the list.

But the article was published on September 3, 2026, and the question it asks was answered on August 13. Identity attributes are a fixed set of nine attributes that Databricks stores on account users, synced from your identity provider: title, department, cost centre, country, and five more. Four days later, on August 17, ABAC column mask policies gained conditions that target users by attributes synced from your identity provider, and on August 21 context attributes let policies target the context of a request, such as the calling OAuth application. That is the "golden use case" the article describes: a user attribute evaluated against a data attribute, in one policy.

The caveats are real and worth stating plainly. All three are Beta. Identity attributes are supported on users only, not on groups or service principals. They work in column masks, not yet in row filters. And they are attributes, not tags, so the literal sentence "you cannot tag a user" stays true.

The UDF-wrapper part also overstates things. An Attribute-based access control (ABAC) policy has a TO clause naming the users, groups, or service principals the policy applies to. Targeting a group does not require a UDF.

Verdict. Partly holds. No user tags, true. No way to evaluate user attributes in a policy, false since August 17, 2026, with Beta limits. Misleading: stale by two weeks on the point the whole section rests on.

Security: differential privacy

The claim. Databricks has no native differential privacy policies or privacy budgets, and leaves that layer to manual auditing or third-party tools.

The docs. Databricks Clean Rooms are described as an environment where parties work on sensitive data without direct access to each other's data. That page does not mention differential privacy, noise, or a privacy budget. We searched the Databricks docs for a native differential privacy policy and found nothing.

Verdict. Consistent with the docs, as far as we can see. Not misleading.

Sharing: the recipient penalty

The claim. Delta Sharing shifts cost and complexity to the recipient: recipients bring and pay for their own compute, often copy the data locally anyway, and multi-tier re-sharing is restricted by rigid recipient requirements.

The docs. Start with the name. The article says "Delta Sharing" throughout. Databricks renamed it: on June 10, 2026, Delta Sharing is now OpenSharing. The old name is Delta Sharing; the current name is OpenSharing. Snowflake is using a name that was three months out of date at publication. We track exactly this kind of thing, so we notice.

On compute, the article is right. OpenSharing is an open protocol developed by Databricks for secure data sharing, and open-sharing recipients read it with their own tools. The docs give instructions for reading shared data using the following tools: Iceberg clients, Apache Spark, pandas, Power BI, and Tableau. Whatever runs those is the recipient's, and the recipient pays for it.

The article also says recipients "often end up building custom ingestion pipelines to copy the data locally anyway". That is a claim about what recipients do, not about what the product does, and no documentation can confirm or deny it. What the docs say is that OpenSharing is designed so that copying is not required, below.

On egress, the article never says outright that Databricks recipients pay it. It says Snowflake's approach means "removing egress for the consumer", which leaves the reader to infer that the alternative does not. The Databricks docs point the other way. The egress page is titled "for providers". OpenSharing does not require data replication, so your cloud vendor may charge data egress fees when you share data across clouds or regions. That "your" is the provider. OpenSharing within a region incurs no egress cost. For cross-cloud, the provider can place data where Cloudflare R2 object storage incurs no egress fees, or use SecureConnect, where Databricks bills the data transfer rather than your cloud vendor.

On re-sharing, the docs have one rule, and it points the article's way. The create-share page lists as a limitation that you cannot share views that reference shared tables or shared views. That closes the obvious route to multi-tier sharing: receive a table, wrap it in a view, share the view on. Whether a recipient can add a received table to a share directly is not stated anywhere we could find, in that page, in the SQL reference for adding tables to a share, or in the OpenSharing specification repo, whose spec has no concept of a recipient re-sharing at all. So "restricted" is fair; how restricted is not fully written down. What the docs also say is that a shared catalog is read-only: you cannot grant privileges that give write or update access to an OpenSharing catalog.

Verdict. Compute cost to recipients holds. The implied egress cost to recipients does not hold; the docs put it on the provider. "They copy it anyway" is behaviour, not documentation. Re-sharing is partly documented: views over shared data cannot be shared on, and the docs stop there. The compute point is misleading by framing: the article's own Snowflake pitch has consumers query "using their existing warehouses", which they also pay for. The egress implication is misleading. "They copy it anyway" is unsupported. The re-sharing restriction is not misleading; the one rule on record supports it.

Continuity: managed disaster recovery

The claim. Databricks Managed Disaster Recovery does not replicate materialized views, streaming tables, Lakeflow pipelines, secrets, ML models, model serving endpoints, vector search indexes, Delta shares, published dashboards, or Structured Streaming outside Lakeflow. Customers must recreate external locations and storage credentials in the secondary region. After failover, SQL warehouses arrive stopped, clusters terminated, and job schedules paused. Initial replication can take up to two weeks. Cross-cloud needs DIY scripts.

The docs. This is the most accurate section of the article. Every item is on the page. Managed DR replicates your Databricks deployment to a secondary region, and you do not write or maintain replication scripts. The not-replicated list includes Unity Catalog and workspace secrets, ML models, model serving endpoints, vector search indexes, Delta shares, plus materialized views, streaming tables, and pipelines. Managed DR does not replicate external locations or storage credentials automatically. SQL warehouses are replicated in STOPPED state, clusters in TERMINATED state, and job schedules in the secondary are paused. For large workspaces, the initial workspace asset bootstrap can take up to two weeks. The secondary must be on the same cloud as your primary, so cross-cloud is indeed outside the product.

One sentence in the article overreaches. It says that "true cross-region or cross-cloud resilience" requires teams to write and maintain custom synchronization scripts. Cross-cloud, yes. Cross-region is what managed DR is: it replicates to a secondary region, and the page's own words are that you do not write or maintain replication scripts. The gaps listed above mean some objects still need manual work after failover, which is a fair point. "Cross-region needs DIY scripts" is not.

Two things the article omits. First, this is a Public Preview since June 12, 2026, and access to managed disaster recovery is currently gated, sold through the Mission Critical add-on. Comparing a gated preview to a product Snowflake has shipped for years is fair to mention, and the article does not. Second, a small irony for this site: the not-replicated list on Databricks' own page still says "Delta shares", three months after Databricks renamed Delta Sharing.

Verdict. Holds on every listed gap. "Cross-region needs scripts" does not hold. The gap list is accurate and not misleading. The cross-region sentence is misleading.

Money: the consumption penalty

The claim. Databricks runs standard DBU consumption with minimal financial incentives to optimise, so a faster job just earns the vendor less.

The docs. This is opinion, and the argument applies to any consumption model, Snowflake's included. What the pricing page says is that Databricks offers discounts when you commit to certain levels of usage, which is the same shape as the "capacity commitments" the article credits Snowflake with.

Verdict. Opinion. The one checkable fact, that commitment discounts exist, points the other way. Misleading by omission.

What to take from this

Counting the scorecard: the disaster recovery section is fully accurate, the UniForm and compute-tuning claims are accurate about classic compute, and the RBAC quote and dates are exact, and so is the read-only Iceberg point once "outbound" is read as "outbound writes". The egress direction and the "you can't" on user attributes do not survive a read of the docs. The commit-share footnote does not survive a clone of the repos. The product name is three months out of date. On the second verdict, 12 of 26 claims mislead, 2 partly, 9 do not, and 3 cannot be checked. The misleading ones are rarely false outright. Most are true sentences about classic compute, or about the docs as they stood a few weeks earlier, with the part that would change the reader's mind left out.