The modern data stack is fundamentally broken

Here's a fun exercise. Count the purchase orders between "we have data" and "someone answered a question with it" at a company running the modern data stack.

You need an ingestion vendor to copy data out of your SaaS tools. You need a cloud warehouse to put it in. You need a hosted transformation platform to turn the raw copies into something usable, and an orchestrator to run it all on a schedule. That's four vendors, four procurement cycles, four onboarding calls with a customer success manager — each one starting at five figures a year, and that's the entry price, before usage-based billing finds its stride.

And here's the part that should make you angry: at the end of all that, you still haven't shipped anything. You've built a capability. The stack is up, the DAG is green, the invoices are recurring — and the actual thing someone wanted, a trustworthy answer served to a dashboard or an app, is still a ticket in the central data team's queue.

Worse: every problem you had before the stack, you still have. Nobody agrees on what "revenue" means. The dashboard broke because someone renamed a column. The question that started this whole journey is three sprints deep in a backlog. You didn't buy solutions to those problems. You only bought a more expensive place for them to live.

Then the second wave of vendors shows up to sell you solutions to the problems the first wave created. A data observability tool, because nobody can tell when a pipeline silently breaks. A data catalog, because nobody knows what any of the 4,000 tables are for. A reverse-ETL tool, because after paying to move data into the warehouse you now need to pay to move it back out. Each of these is a real product solving a real problem, but the problem is downstream of an architectural choice nobody remembers making.

Everything software learned not to do, sold back to you as architecture

Twenty years ago, software worked the way data works now. There was a central IT team. You filed a ticket to get a server. Applications were monoliths deployed by an ops group that didn't write them, on a schedule measured in quarters, and the people who understood the code and the people who ran it in production were different people who communicated by blame.

Software didn't fix that by buying better ticketing systems. It changed the shape of ownership. Monoliths broke into modules and services with explicit interfaces. "You build it, you run it" replaced the wall between dev and ops. The central team stopped being a gatekeeper that did everyone's work and became a platform team that paved roads for others to drive on. Nobody walked it back, because it worked.

Data is the last department still running the old playbook — and the modern data stack didn't retire it, it renovated it. A central team, a shared monolith, a ticket queue, and a release process everyone routes around. And the monolith at the center is worse than an organizational throwback; it's a technical one. Look at what the warehouse actually is, in software terms: one global namespace of shared mutable state, where every consumer couples directly to whatever internals are convenient, integration happens by reading someone else's tables, and changes ship with no version bump. Global state. Depending on internals. Integration through a shared database. Breaking changes without versions. Every one of those is a named antipattern that fails code review in software. Stacked together, in data, they're the reference architecture.

So the breakage isn't bad luck, it's destiny. In the warehouse, every table is reachable, so every dashboard, notebook, and ML job wires itself to whatever layer is convenient — staging, intermediate, mart — and none of those dependencies are declared anywhere. Your "use case" is a fuzzy region of a spaghetti DAG. No table can tell you which use case it exists for, what it promises, or whether it's safe to delete. Every column you ship might be load-bearing for a dashboard you've never heard of, so when someone renames it, there's no deprecation notice — it just breaks on a Tuesday, and the postmortem is a Slack thread. Ownership goes diffuse, every change starts with archaeology, and development slows to the speed of fear, with a central team holding it together through tribal knowledge and human toil. That's what the five figures × N vendors actually buys: the organizational pattern software spent two decades escaping, implemented on top of the technical patterns software spent two decades banning, with a subscription ring of tools to make living inside it more comfortable.

A pipeline doesn't fix this, because a pipeline has no edges. Where does it start? Where does it end? What does it promise? Who is allowed to use it? Those answers live in someone's head, a wiki page, and three Slack threads.

The way out is not another vendor

If the diagnosis is "the monolith has no boundaries," the fix isn't a fifth subscription that monitors the boundaries you don't have. The fix is the same one software found: a unit of ownership with private internals, an explicit versioned interface, and a name on it. Data has that unit now — it's called a composable data product, and we wrote up exactly what it is.

The part worth stressing: it's not a rip-and-replace. A composable data product is compatible with the modern data stack, not a competitor to it. Your warehouse doesn't disappear; it becomes one input among others. The stack keeps doing what it's genuinely good at — one shared model, operated by one team — and the use cases that never needed all that get edges, contracts, and owners instead of a spot in the queue.

Software made this turn twenty years ago and never looked back. Data's turn is overdue.