The question shows up in the first half hour of nearly every MDM architecture review: should this run on Databricks or Snowflake? Usually the team has already standardized on one, or is halfway through a migration to the other, and master data is the workload that refuses to sit quietly in either. What follows is a feature bake-off, a weighted scorecard, and a decision nobody fully believes — because the scorecard assumes master data management is one workload.
It isn't. A working MDM program is at least five distinct workloads, and they want genuinely different things from a platform. Two of them are easy on either side. One has a defensible winner. And two of them — the two that almost never get scoped properly at the start — are where the architecture is actually decided.
| Workload | What it demands | Shape of the load |
|---|---|---|
| Ingest and standardize | Broad connectivity, tolerance for schema drift, cheap reprocessing when a rule changes | Batch, bursty, throughput-bound |
| Match and merge | Iterative modelling, pairwise blocking at scale, a human labelling loop that runs for months | Batch, compute-heavy, experimental |
| Survivorship and golden record | Deterministic rules, versioning, lineage granular enough to answer “why this value?” | Batch, modest volume |
| Serving the golden record | Point lookups in milliseconds, high concurrency, availability measured against a downstream SLA | Operational, steady, latency-bound |
| Stewardship and workflow | Row-level writes, real transactions, dozens of concurrent users, sub-second reads | Operational, small volume, latency-bound |
Read that table and the shape of the problem changes. The first three rows are analytical: batch-oriented, throughput-bound, perfectly happy with a few minutes of latency and an occasional full reprocess. The last two are operational. They want row-level transactions, they want them fast, and they want them at nine in the morning when four hundred people open the stewardship console at once. Choose a platform on the strength of the first three rows and you will win the bake-off and lose the project, because the console and the golden-record API are the only parts of an MDM program the business ever actually touches.
Figure 1. The three analytical stages sit comfortably on either platform. The dashed line is where the architecture is actually decided — and the feedback loop underneath it is the part most designs forget.
Ingest and standardize: a tie, decided by your source mix
This is the least interesting part of the decision, and it is where most evaluations spend the most time. Both platforms ingest from everything, both handle schema drift, both let you reprocess history when a standardization rule changes. Snowflake's story is tighter if your sources are already relational and your team writes SQL; Databricks is more comfortable when a meaningful share of your master data arrives as PDFs, scanned supplier forms, product images, or free-text service notes, because you are not leaving the platform to parse them.
One thing has changed here in 2026 and it is worth registering: the open-table-format argument is over. Snowflake shipped Apache Iceberg v3 support with bidirectional read and write against external catalogs through Polaris, plus Snowflake-managed Iceberg storage on AWS and Azure. Databricks made Unity Catalog managed tables writable by external engines in public preview and added native geospatial types across Delta and Iceberg v3. Neither platform can credibly claim your data is trapped there any more, which means storage lock-in is a weaker argument than it was two years ago and should carry less weight than it usually does in these reviews.
Match and merge: Databricks, unless your matching is simpler than you think
This is the one row with a defensible winner, and the reason is not raw compute. It is the loop. Probabilistic matching is never configured once. You block, you score, you sample the borderline pairs, you put them in front of a steward, you take the labels back, you retrain, and you do it again next quarter when a new source lands with a different address format. That loop wants experiment tracking, versioned models, and a runtime where the open-source record-linkage ecosystem already lives — Splink, Zingg, dedupe, and the Spark-native accelerators Databricks itself publishes. On Databricks that is a Tuesday. On Snowflake you can absolutely do it through Snowpark and container services, but you are porting Spark-shaped tooling into a different runtime and rebuilding the scaffolding that came free on the other side.
The honest counterargument is that a lot of enterprise matching is not probabilistic at all. If your customer master keys on a tax ID and a standardized address, and your product master keys on a GTIN, then you have a deterministic problem wearing a probabilistic costume, and you will pay for an ML surface you never open. Snowflake's Cortex AISQL has also narrowed the gap for the middle cases: text similarity and attribute comparison expressed as ordinary SQL functions, with AI_COMPLETE now taking audio and video alongside text and images. For a SQL-first team, that path reaches a usable first result in hours rather than weeks. It will not carry you to a tuned, explainable, audited match engine — but plenty of programs do not need one.
| Capability | Databricks | Snowflake |
|---|---|---|
| Open-source record linkage (Splink, Zingg, dedupe) | First-class on Spark; vendor-published solution accelerators exist | Runnable via Snowpark or containers; you are porting, not adopting |
| Blocking across hundreds of millions of records | Shuffle is the native primitive; cluster shape is yours to tune | Warehouse scale-out handles it; SQL-expressed blocking gets awkward past a few strategies |
| LLM-assisted matching on messy attributes | Model Serving plus any open model, in the same job as the rest of the pipeline | Cortex AISQL as plain SQL functions — markedly lower effort to start |
| Human-in-the-loop training cycle | MLflow tracking and model versioning are the default path | Possible, but you assemble the loop yourself |
| Time to a first usable result, SQL-only team | Weeks, and a Spark skill dependency you must staff | Hours to days |
Survivorship: neither platform has an opinion, which is the problem
Survivorship is rules — most recent wins, most trusted source wins, longest non-null value wins, and the forty exceptions your business has accumulated. Both platforms will execute those rules perfectly well, and neither gives you anything resembling a survivorship engine out of the box. What matters is whether the result is explainable eighteen months later, when a regional finance lead asks why the billing address on an account changed and someone has to answer with more than a shrug.
That is a lineage question, and it is where the two catalogs diverge slightly. Unity Catalog's external lineage went GA in 2026 and now spans upstream operational sources through to downstream BI reports, with Lakeflow Connect pipelines recording lineage automatically — useful precisely because the survivorship answer usually lives partly outside the platform. Snowflake's in-platform lineage is strong, and Horizon Context now auto-generates semantic views from existing SQL, Tableau, and Power BI assets, which is a different and genuinely clever bet: infer the business meaning rather than make someone document it. Both are moving toward the same place. Today, if the audit trail must cross a platform boundary, Databricks is a little further along.
Serving the golden record: the first decision that actually matters
Here is the failure mode we see most often. A team builds a beautiful matching pipeline, lands golden records in a Delta or Snowflake table, and then discovers that the order-capture application needs a customer lookup in under fifty milliseconds at a few thousand requests per second. An analytical table will not do that, so someone bolts on a cache, and now there are two copies of the golden record with no agreed answer about which one is authoritative during a sync lag. That is not a platform failure. It is a scoping failure — the serving tier was never designed, only assumed.
The good news is that both vendors spent 2025 and 2026 closing exactly this gap, from opposite directions. Databricks brought a managed Postgres — Lakebase — into the lakehouse and made it registrable in Unity Catalog, so the operational store is a governed object rather than a shadow system. Snowflake pushed Unistore forward: Hybrid Tables have been generally available on AWS commercial regions since November 2024, and the 2026 engine optimization in public preview claims roughly an eightfold improvement in latency and throughput. Snowflake also now offers managed Postgres in its own right, generally available since February 2026 with Private Link, customer-managed keys, and secrets integration, plus Postgres data mirroring into Snowflake in public preview. Both platforms will now serve your golden record. The choice is about which serving model your team can operate.
| Option | What it is | Best fit | Watch out for |
|---|---|---|---|
| Databricks Lakebase | Managed Postgres beside the lakehouse, registrable in Unity Catalog | Golden-record APIs, feature serving, and the stewardship app’s backing store | Sync semantics between Postgres and Delta are still yours to design and test |
| Snowflake Hybrid Tables (Unistore) | Row store and column store in one table, GA on AWS commercial regions since late 2024 | Point lookups on golden records without a second system or a second copy | Default database size limits and narrower region coverage than the rest of Snowflake |
| Snowflake Postgres | Managed Postgres under Snowflake governance, GA since February 2026 | Teams that want Postgres semantics without leaving the Snowflake control plane | Young; mirroring direction and replication lag need testing against your SLA |
| External key-value store | Redis, DynamoDB or Cosmos DB fed from either platform | Hard single-digit-millisecond SLAs and extreme concurrency | A third system, a third failure mode, and a consistency contract you own outright |
Stewardship: the second decision, and the one that gets skipped
A stewardship console is a transactional application. Stewards claim tasks, hold locks, write decisions, and expect the screen to respond while forty of their colleagues do the same. It also generates the single most valuable dataset in the whole program — human adjudications of hard match cases — which needs to flow back into the training loop rather than sitting in an audit table nobody reads. That feedback path is the dashed line at the bottom of Figure 1, and in our experience it is missing from more MDM designs than it is present in.
If you are building the console yourself, this decision follows the serving decision exactly: whichever operational store you picked in Table 3 is where the console's state lives, and you should build it against Postgres semantics unless Hybrid Tables give you a reason not to. If you are buying an MDM platform, the console comes with it and this row disappears from your evaluation entirely — which is a much bigger deal for the overall comparison than most teams realize, and worth a section of its own.
Governance: two catalogs converging on the same idea
Unity Catalog and Horizon Catalog spent 2026 chasing the same target from different starting points, and the target is not really data governance any more — it is governing what agents are allowed to do with data. That matters for MDM specifically, because the golden record is about to become the thing autonomous systems resolve identity against, and an agent that merges two customers on a bad match causes damage no dashboard would.
| Concern | Unity Catalog | Horizon Catalog |
|---|---|---|
| Business semantics | Domains in public preview, Glossary previewing, Metrics with materialization | Horizon Context auto-generates semantic views from existing SQL and BI assets |
| Fine-grained access | ABAC grant policies in beta, identity and context attributes previewing, tag propagation through transformations | Intent-driven governance in private preview — policy expressed in natural language, classification triggered automatically |
| Lineage reach | External lineage GA, upstream sources through downstream BI | Strong in-platform; cross-platform breadth is the softer spot |
| Agent governance | Unity AI Gateway in beta, governing model, agent, MCP and tool interactions with spend tracking and tracing | Agent identity with policies that distinguish agent from human, and AI guardrails GA against prompt injection |
| Open table interoperability | Managed tables writable by external engines in public preview | Iceberg v3 GA with bidirectional catalog read and write via Polaris |
The practical read on Table 4 is that neither catalog is a reason to switch. If you already have a governance model built, roles mapped, and tags propagating on one of these platforms, that investment outweighs every line item above. Running two governance models so that MDM can live on the other platform is the most reliably expensive decision available in this whole comparison, and it rarely appears on the scorecard at all.
The answer is often “both” — which is fine, if you name the boundary
A significant number of enterprises will end up running master data across both platforms, and not because anyone chose to. Acquisitions arrive with their own stack. A business unit standardized differently. The data science group went to Databricks in 2022 while finance stayed on Snowflake. Iceberg interoperability has made this arrangement technically painless in a way it was not two years ago — you can genuinely match on one platform and serve analytics from the other without copying the data twice.
Technically painless is not the same as organizationally safe. Split architectures fail on a question that has nothing to do with either vendor: when the two sides disagree, which one is right? If the match job runs on Databricks at 02:00 and a Snowflake pipeline writes a corrected address at 02:15, the golden record has two values and the answer depends on which query someone happened to run. That is not a sync bug you fix later. It is an ownership question you either settle in the design or discover during an audit.
So if you are running both, write down three things and circulate them wider than the architecture team. First, which platform holds the system of record for each domain — per domain, not globally, because customer and product often land in different places for perfectly good reasons. Second, the maximum acceptable propagation lag between them, expressed as a number, with an alert attached to it. Third, who is allowed to write to the golden record and through which interface; a split architecture with two write paths will develop a third within a year. None of this is exotic, and it is almost never documented.
The version of this that works is deliberate: matching and stewardship consolidated on one platform because that is where the loop and the console live, golden records published outward to the other as a governed, read-only, clearly-labelled downstream copy. The version that fails is the one where both platforms hold writable master data and nobody wrote down which one wins. We have walked into that situation more than once, and the remediation is always more expensive than the migration would have been.
The uncomfortable question: are you actually building this?
Most enterprises asking the Databricks-or-Snowflake question are not building an MDM platform from scratch. They already own one — Informatica, Reltio, Semarchy, Stibo, or a stack inherited through an acquisition — and the real question is where the golden records land and which platform the vendor invests in first. That reframes everything above, because the vendor's roadmap will make this decision for you whether or not you participate.
The 2026 evidence is worth reading closely, because it is asymmetric. Informatica, now part of Salesforce, announced headless data management for both platforms — IDMC microservices such as metadata search and address validation invocable through MCP servers inside Databricks Agent Bricks and inside Snowflake Cortex AI, private preview moving to general availability over summer 2026. But the MDM-specific capability went to one side: an MDM Extension for Databricks that publishes trusted golden records directly into Databricks SQL, with pre-configured schemas for the Customer, Supplier, Product, and Location domains and hierarchy extraction included, targeted at the October 2026 release. Unity Catalog tag extraction into Informatica's own catalog has been available since April 2026. Snowflake got the headless Cortex integration; Databricks got the golden-record pipe. That gap may close, and Reltio and others maintain their own Snowflake integrations — but if you are an Informatica shop planning a 2027 architecture, the shortest supported path currently points at Databricks, and you should confirm that against your vendor's roadmap rather than against this article.
The corollary is liberating: if you are buying, rows two and five of Table 1 leave your evaluation entirely. The vendor does the matching and supplies the console. What you are choosing is an analytics and serving target, which is a much smaller decision than the one you started with — and one where staying on your existing platform is almost always right.
Cost behaves differently than the pilot suggests
MDM has an unusual cost profile: a heavy, bursty, occasional batch alongside a light but permanently-on operational tier. Pilots only ever exercise the first half, which is why the invoice surprises people in month four rather than month one.
For the batch half, both platforms have improved in ways that matter here. Snowflake's Adaptive Compute is rolling out to general availability with automatic warehouse sizing billed on actual usage, and the new interactive compiler cut compilation dramatically on large workloads — both of which suit a match job that runs for ninety minutes once a night and nothing in between. Databricks pricing rewards the same discipline through job clusters and workload-tier separation. Either way, the batch tier is a solved problem if someone owns it. We have written separately about what happens when nobody does, in our guide to warehouse cost discipline.
The operational half is where the modelling usually goes wrong. A serving tier is always on by definition; it does not scale to zero at two in the morning because that is when the European order feed runs. Lakebase is billed pay-as-you-go with committed-use discounts available; Hybrid Tables consume Snowflake compute continuously in a way an analytical warehouse does not. Neither is expensive in isolation. Both are expensive if you sized them from a pilot that only ever ran the matching job. Model the serving tier at production concurrency before you sign anything, and model it for both platforms — the ranking flips depending on your read-to-write ratio more often than vendors like to admit.
A decision guide, with the honest tie-breakers
| If this is true of you | Lean | Why |
|---|---|---|
| You already have a governance model, roles and tags built out on one platform | Stay where you are | Nothing else in this article outweighs the cost of a second governance model |
| Your MDM is a licensed platform and the lakehouse is downstream of it | Follow the vendor roadmap | Golden-record publishing and connector investment are landing unevenly across the two platforms right now |
| Matching is probabilistic, multi-domain, and you expect to retrain it | Databricks | The labelling and retraining loop is the actual job, and it already lives there |
| Matching is mostly deterministic on a few standardized keys | Snowflake | You would be paying in complexity for an ML surface you never open |
| A meaningful share of master data arrives as documents, images or free text | Databricks | Parsing and matching stay inside one runtime instead of two |
| Golden records must serve an application under a hard latency SLA | Decide the serving tier first, then the platform | Region coverage, preview status and your read-to-write ratio decide this, not the brand |
| Your team is SQL-first with no Spark capability and no plan to hire it | Snowflake | A platform your people cannot operate is not cheaper for being more capable |
What we would insist on
Three things, on any MDM build, regardless of which side of this comparison you land on.
Design the serving tier in week one, not week thirty. Write down the latency target, the concurrency at peak, and the consistency contract between the analytical golden record and whatever answers the API. If you cannot write those three numbers down, you do not yet have an architecture — you have a matching pipeline and an assumption. This single omission causes more late-stage MDM rework than every other design error we encounter.
Close the steward feedback loop before go-live. Every adjudication a steward makes is a labelled training example, and a program that discards them is choosing to have the same match quality in year three as in year one. Make the path from console decision to model retraining an explicit, scheduled, owned pipeline. It is a week of work at the start and effectively impossible to retrofit once the console is in production.
Benchmark the two decisions that matter, and only those. Do not run a general platform bake-off. Run your actual match job at production volume on both, and run your actual serving pattern at production concurrency on both. Two focused tests over two weeks will settle this argument more convincingly than a scorecard with forty rows, and they cost less than the first month of the wrong choice.
The broader point is that the golden record is no longer a reporting asset. It is becoming the thing agents resolve identity against before they act, which raises the cost of getting the operational half of this architecture wrong — a theme we picked up in From Golden Record to Golden Agent. If you are weighing this decision now, or living with the consequences of one made two years ago, talk to our data architecture team — we would rather help you benchmark the two tests above than review another scorecard.
