The 9-Plane Data Platform: Why We Stopped Bolting Tools Together

If you sketch the average enterprise data stack on a whiteboard, you get something like this:

Airflow → Snowflake → dbt → DataHub → Looker → PagerDuty → DataDog → some-AI-thing-they-bought-last-quarter

Seven boxes. Seven logins. Seven RBAC models. Seven audit trails. Seven bills. Seven on-call rotations. The diagram looks fine. The reality is that the team spends 30% of its engineering capacity just keeping the seams from leaking.

That's the problem D-Pulse was built around. The fix isn't a bigger box. The fix is a different shape — a data operating system organized as nine planes instead of nine products.

Why "platform" became a marketing word

"Data platform" used to mean something. It meant you owned the layer below the application — the database, the queue, the cache — and the application engineers built on top. The platform team gave them a stable substrate.

Then the modern data stack happened, and "data platform" started meaning "the bag of SaaS tools we pay for." Each tool is good at its one job. Each tool has slick onboarding. Each tool slots into a slide in a pitch deck. None of them know about each other.

The result is that data teams have less platform than they did fifteen years ago. They have more tools, but the seams between the tools are where every real production problem happens. Pipeline writes a column. Catalog doesn't pick it up for two days. Governance policy was never updated. BI dashboard breaks. Finance partner pings on Slack. Engineer spends an afternoon tracing it.

This is not a tooling problem. This is a system problem.

What we mean by "9 planes"

A plane is a slice of the platform that owns one concern end-to-end. It has its own data model, its own API, its own scaling profile, its own failure mode — and it shares identity, lineage, and policy with every other plane through the platform substrate.

The nine planes in D-Pulse are:

1. Pipeline — how data moves
2. Lakehouse — where data lives
3. Catalog — what data exists
4. AI — how data is queried, generated, and reasoned about
5. Governance — who can do what
6. Observability — is it healthy
7. Serving — how data leaves
8. Connector — what data plugs in
9. Execution — how work runs

That list isn't arbitrary. We arrived at nine the slow way — by building it, watching what broke, and noticing which concerns kept needing to be in their own service to stop fighting each other. Eight wasn't enough (Execution kept getting tangled with Pipeline, and that's where workload management problems came from). Ten was too many (early splits between Catalog and Lineage merged once the lineage graph stabilized).

Some teams will look at that list and say "we already have all of those." Right — but you have them as separate products. The architectural claim isn't that the concerns are new. It's that they should live in one substrate instead of nine.

The argument against the 5-tool stack

Three things break when your platform is five products in a trench coat.

1. Identity drift. Each tool has its own users, groups, and roles. You sync them with SCIM if you're disciplined and with shell scripts if you're honest. A new hire takes a week to get fully provisioned. A leaver stays in some tools for months. RBAC means "matching strings across five admin panels."

In a single-substrate platform, identity is one thing. Add a user once, set their role once, and every plane sees it the same way at the same time. Off-boarding is a single revoke.

2. Lineage gaps. Every cross-tool transition is a place where lineage breaks. Pipeline tool writes to warehouse, dbt transforms, BI tool reads, AI tool queries — and the lineage graph is stitched together by a separate catalog product that scrapes metadata from all of them, days late, with column-level resolution failing on edge cases.

In a single-substrate platform, lineage is recorded in the request path, not reconstructed afterward. When a query runs, the dependency is captured. When a transform writes, the column-level mapping is captured. There is no scraping. There is no drift.

3. Policy fiction. Compliance teams write policies. Engineering teams implement controls. The policies and the controls are connected by Confluence pages and trust. Audits become large theatrical events because nobody can produce evidence that policy X is enforced everywhere it should be.

In a single-substrate platform, policies are declarative artifacts that the substrate enforces at every read and write. You don't trust that the rule is being followed — you can prove it from the audit log, because every access went through the same policy engine.

Why not a monolith

The obvious counter-argument: if planes need to share so much state, why not just make it one big service? Build it as a monolith and ship it.

Because the failure modes don't share. The Lakehouse plane is stateful and storage-bound. The AI plane is bursty and GPU-bound. The Pipeline plane is long-running and orchestrator-bound. The Catalog plane is read-heavy and search-bound. The Execution plane is throughput-bound. A monolith forces all of them onto the same scaling profile, which means the slowest one becomes the bottleneck for everyone.

A 9-plane architecture lets each plane scale independently. The Lakehouse plane can run on one node count, the AI plane on another, the Pipeline plane on a third. When a plane fails, the others degrade rather than cascade. When a plane gets a new release, it ships without coordinating with the others.

The cost is real — nine services is more to operate than one. The tradeoff buys you the ability to actually run the system in production at scale.

Why not nine separate products

The other obvious counter-argument: if each plane has its own scaling profile, why not just buy nine separate products like the modern data stack does?

Because the substrate is what makes the planes work as a system. Identity, lineage, policy, audit, observability — these aren't features inside any plane. They're the connective tissue between the planes. When you buy nine separate products, the substrate doesn't exist, and you spend the next two years trying to retrofit it with sync jobs and duct tape.

The 9-plane architecture is what you get when you put the substrate first and let the planes hang off it, instead of the other way around.

What it actually looks like in production

Concretely, here's what changes when you run on a 9-plane platform instead of a 5-tool stack:

• A new hire is fully provisioned in under five minutes, because there's one identity to provision.
• A field-level data classification on a source column propagates through every downstream pipeline, mart, and dashboard without anyone touching them — because the Governance plane is in the request path of every query.
• An on-call alert points at the failing pipeline node, the upstream table that broke, and the downstream dashboards that will be wrong, in one screen — because the Observability and Catalog planes share a graph.
• An analyst can ask "what changed in the orders table this week" in natural language and get a column-level diff with lineage, because the AI plane has direct access to the Catalog plane.
• A compliance audit is a SQL query against the audit log, not a six-week project.

These aren't features you bolt on. They're consequences of the shape.

Where the trade-off bites

This design isn't free. Three places where the 9-plane model is the harder choice:

Up-front complexity. Building nine planes is a multi-year project. You don't get to ship fast and figure out the seams later — the seams are the entire point.

Vendor lock-in concern. A monolith-of-planes is, by definition, one vendor's view of how data work fits together. If you don't like how D-Pulse models a plane, you can't swap that plane out for someone else's. The mitigation is that planes are individually replaceable internally and externally — you can point the AI plane at any of nine LLM providers, you can point the Lakehouse plane at Snowflake or Databricks instead of the native engine — but you can't replace the Catalog plane with someone else's catalog product. That's the cost of substrate consistency.

Migration friction. You can't drop a 9-plane platform into an existing 7-tool stack without a real plan. The right migration is plane-by-plane, starting with Catalog (which can crawl your existing tools and immediately add value without replacing anything), then Governance, then Pipelines for new work. Full cutover is a quarter or two, not a weekend.

If those costs scare you off, that's fine — D-Pulse isn't the right fit for every team. F-Pulse is the right starting point if you only need the Pipeline plane today. Pulse-Agent is the right starting point if you have an existing stack you don't want to replace and just need a brain on top of it.

The bottom line

The 9-plane data platform isn't a marketing diagram. It's an architectural claim: the data work that matters needs nine concerns to be held together by one substrate, and the substrate is what the modern data stack forgot to build.

If you've ever spent a Friday afternoon tracing why a number on a dashboard doesn't match a number in a spreadsheet, you already know the cost of the substrate being missing. We built D-Pulse because we got tired of paying that cost. If you want to see the architecture in detail, the 9-plane deep dive walks through each plane and what it owns.

Stop bolting tools together. Build on a substrate.