The Modern Data Stack Got Too Complex: The Case for Consolidation

For a decade, the prevailing wisdom in data was that unbundling won. Pick the best ingestion tool, the best warehouse, the best transformation framework, the best orchestrator, the best catalog, the best reverse-ETL pipe, the best observability layer, the best semantic layer, and the best BI tool on top, wire them together, and assemble a stack superior to anything a single vendor could offer. The argument was sound at the time, and it produced a generation of excellent point tools. It also produced something nobody designed on purpose: a data architecture with a dozen vendors, a dozen contracts, a dozen failure modes, and a team whose real job became keeping the seams from splitting.

The contrarian thesis is that the modern data stack has passed peak fragmentation. For most teams, the integration tax now exceeds the benefit of best-of-breed, the marginal point tool no longer earns its seat, and the pendulum is swinging back toward consolidation. This is not nostalgia for the monolithic data warehouse of the past. It is the recognition that the conditions that made unbundling rational, dumb warehouses and slow incumbents, have largely reversed, and that the costs of a sprawling stack, most of them hidden, have compounded to the point where a leaner, more consolidated architecture is the higher-performing choice for the majority of organizations.

This matters because data leaders are still being sold the unbundled vision at a moment when the economics have flipped, and because the warehouse and lakehouse vendors are quietly absorbing the adjacent layers in a way that will make much of the current stack redundant. What follows is why unbundling made sense and no longer does, where the hidden costs actually hide, why the platform vendors are eating the point tools, a direct comparison of the unbundled and consolidated approaches, and a framework for deciding what a lean team should collapse and what it should keep separate.

Why Unbundling Was Right, And Why That Changed

The unbundled stack was a rational response to a specific deficiency. A decade ago the data warehouse was, in effect, a dumb store: good at holding data and answering SQL, bad at almost everything else. It could not transform data well, could not orchestrate workflows, could not stream, could not serve a semantic layer, and could not do machine learning. So the ecosystem routed around the warehouse's limitations by building specialized tools for each missing capability, and connecting them with pipelines. Best-of-breed was not a preference. It was a necessity, because the center of the stack could not hold the weight.

That premise has eroded from both directions. The warehouse and the lakehouse stopped being dumb. They absorbed transformation, scheduling, streaming ingestion, governance, and increasingly machine learning and serving, turning the center of the stack into a capable platform rather than a passive store. The convergence of the warehouse and the data lake into a single architecture, traced in the breakdown of the data lakehouse versus the data warehouse, means the thing in the middle can now do natively what teams used to bolt on from the outside. At the same time, the operational databases improved enough that a meaningful share of analytical work no longer needs a separate analytical system at all, a shift captured in the case for Postgres eating the database stack. When the center can do the job, the specialized satellite tools that existed only to compensate for the center's weakness lose their reason to exist.

The result is that many teams are running an architecture designed for a constraint that no longer binds. They are paying the full integration cost of unbundling to solve a problem the platform now solves natively, which is the textbook definition of a stack that has outlived its rationale.