Keep Fivetran. Keep Databricks. Add a Control Plane.

Why modern data teams do not need another ingestion tool. They need a way to govern what happens after ingestion.

If you already have Fivetran moving data into Databricks, you are not starting from zero.

That is important.

Too many vendors position themselves as if every customer should rip out the stack they already have and replace it with one more "unified" platform. That is rarely what enterprise data teams need. In most cases, the hard problem is not getting data to land somewhere. The hard problem starts after that.

Once data arrives in Databricks, the real questions begin:

• Which data is actually approved for downstream consumption?
• Which teams are allowed to consume which datasets?
• What policies must hold before data can be published?
• How are schema changes validated before they break consumers?
• How do you promote trusted products from raw landing zones to governed serving layers?
• How do you move approved data to other query environments without creating governance sprawl?

Fivetran does not solve those problems. Databricks does not solve those problems by itself either. And that is not a criticism of either product. They were built for different jobs.

This is where DataSurface fits.

DataSurface is not another ingestion product trying to replace Fivetran. It is not another compute engine trying to replace Databricks. It is the control plane that sits above the stack you already have and governs how raw landed data becomes trusted, modeled, policy-controlled, and safely consumable.

The Stack You Already Have Is Not the Problem

The current enterprise pattern is common for a reason:

• Fivetran pulls data out of fragmented operational systems
• Databricks gives you scalable storage and compute
• A catalog describes assets and metadata
• Teams build transformations, dashboards, and downstream stores around that core

That stack is usually good enough to get data moving.

But data moving is not the same thing as governed data products.

Most organizations discover this in "day 2" operations. Raw datasets are landing. New tables are showing up. Teams are building on top of them. Then the friction starts:

• one team reads directly from raw landing tables because it is faster
• another team applies its own local interpretation of the data
• a producer makes a schema change that looks harmless but breaks downstream logic
• sensitive fields get copied farther than anyone intended
• medallion layers become naming conventions instead of enforced boundaries
• platform teams become manual reviewers for every significant change

None of that means the ingestion layer failed. It means there is no control plane governing what happens next.

What a Control Plane Actually Adds

When people hear "governance," they often think of metadata, dashboards, stewardship workflows, or after-the-fact alerts. Those things can be useful. But they do not determine what the system is allowed to do.

A control plane does.

In DataSurface, teams declare the shape of the data ecosystem in code:

• producers and the datasets they publish
• consumers and the datasets they are allowed to use
• runtime environments and approved data containers
• policies for classification, placement, compatibility, and cross-team consumption

That model is not just documentation. It drives validation and runtime behavior.

This changes the operating model in a few important ways.

1. Raw data is not automatically trusted data.

A Fivetran-landed table in Databricks does not become a consumable product just because it exists. DataSurface lets you model it, classify it, apply policy to it, and control which downstream workspaces may consume it.

2. Medallion stops being aspirational.

If you want Gold workspaces to consume Silver but never Bronze directly, that becomes an enforced rule, not a diagram in a slide deck.

3. Schema change becomes governed change.

Instead of discovering compatibility problems after deployment, model validation catches breaking changes before they are merged and promoted.

4. Data movement becomes policy-controlled.

If an approved dataset should be published to a serving store on Azure, on-prem, or another query engine, that movement happens under policy rather than through ad hoc replication decisions.

5. Ownership becomes enforceable.

Teams do not just "own" data socially. Ownership is encoded structurally and validated through repository and model boundaries.

The Better Way To Position Fivetran + Databricks + DataSurface

The simplest message for buyers is this:

Keep the ingestion layer you already trust.
Keep the lakehouse platform you already use.
Add the control plane that makes the whole stack governable.

That division of responsibility is cleaner than trying to force one product to be everything:

• Fivetran handles extraction and landing
• Databricks handles storage and compute
• DataSurface handles model-driven governance, product definition, promotion, and controlled publication

This is also a much easier adoption story than platform replacement. You do not need to start with a massive migration. You can begin by onboarding a small number of Databricks datasets that already exist, then use DataSurface to:

• model them as governed data products
• define who may consume them
• enforce classification and policy rules
• validate changes before promotion
• publish curated outputs to the environments that need them

That means the first proof point is not "Can we ingest data?"

It is:

"Can we turn landed data into trusted, governed, auditable products without rebuilding the stack?"

That is the question most enterprises actually need answered.

Why This Matters More In Regulated Environments

This becomes even more important in industries like financial services, healthcare, insurance, and the public sector.

In those environments, the challenge is almost never just moving data into a central platform. The challenge is proving that:

• approved consumers are using approved datasets
• sensitive data is handled according to policy
• changes are controlled and reviewable
• trusted outputs are separated from raw landing areas
• data can be served into the right operational or analytical environment without losing governance

This is why "catalog plus lakehouse" is not enough on its own.

A catalog can tell you what exists.
A lakehouse can store and process it.
Neither one, by itself, is the thing that decides what should be promoted, who should consume it, and whether the movement is allowed.

That decision layer is the control plane.

A Practical Example

Imagine a bank already using Fivetran to land customer, transaction, and account data into Databricks.

Without a control plane, the likely path looks familiar:

• raw tables land in a Bronze area
• some teams build Silver-style transformations
• other teams skip ahead and query Bronze directly
• multiple Gold outputs appear with inconsistent logic
• sensitive fields spread to places they should not
• upstream schema changes create downstream breakage

With DataSurface in place, the flow changes:

• landed Databricks datasets are onboarded into a governed model
• policies define which zones, teams, and workspaces may consume which datasets
• classification and compatibility checks run before changes are promoted
• curated datasets are designated as the approved products for downstream use
• approved serving copies can be published to the right query environments under policy

Same Fivetran connectors.
Same Databricks platform.
Different operating model.

That is the point.

What DataSurface Is Not

It is worth being explicit about what DataSurface is not:

• not a replacement for Fivetran
• not a replacement for Databricks
• not just a catalog
• not just an orchestration layer
• not just a transformation framework

It is the system that coordinates ownership, policy, compatibility, promotion, and placement across the whole data estate.

That is why it belongs above the tool stack rather than inside one tool category.

The Strategic Shift

For the last several years, the data market has trained buyers to think in tool categories:

• ingestion
• storage
• transformation
• catalog
• quality
• observability

Those categories are real, but the biggest enterprise failures usually happen in the gaps between them.

DataSurface addresses that gap.

It gives organizations a model-driven way to describe what their data ecosystem is supposed to look like, who controls which parts of it, what rules must hold, and how trusted data products move through the system.

So if you already have Fivetran and Databricks, the answer is not "throw them away."

The better answer is:

keep them, and add the control plane that makes them operationally governable.

That is the role DataSurface is built to play.