I’ve been working with databases for over two decades, and I’ve watched a lot of cycles come and go. Right now we’re in one that most people in the industry aren’t talking about yet. We’re in the middle of a swing away from database sprawl and back toward consolidation. The data makes it clear why.

The Data Sitting in Storage is Mostly Useless

Let’s start with something that should keep every CTO awake at night: most of the data you’re paying to store isn’t actually being used.

The numbers are hard to ignore. Forrester Research found that between 60 and 73% of enterprise data goes completely unused for analytics. Market Logic Software put a slightly different frame on it: only about one-third of enterprise data is actually utilized after it’s created. You’re collecting it, storing it, securing it, and backing it up. Two-thirds of it is just sitting there.

This isn’t a storage problem. This is a sprawl problem.

When I talk to engineers about their data architecture, I hear a familiar refrain: “We need a different database for this workload.” It makes sense on the surface. Cassandra is great for time-series. PostgreSQL is great for transactions. Redis is great for caching. Elasticsearch is great for search. Neo4j is great for graphs. Each one is genuinely good at what it does.

But somewhere along the way, the question stopped being “Do we need another database?” and became “Why not? We have the infrastructure.” That’s how you end up with seventeen database technologies in your environment, most of them underutilized, all of them requiring expertise, operational overhead, and monitoring.

That’s not a data strategy. That’s a storage bill with compliance attached.

The Complexity Tax is Getting Expensive

The 2010s were the era of database proliferation. For the first time, organizations had real choices. The monolithic SQL databases of the 90s and 2000s gave way to specialized tools designed for specific problems. It was genuinely exciting. It was also unsustainable.

The bill is coming due, and enterprises are noticing.

Redgate’s 2025 State of the Database Landscape report shows the numbers shifting fast. Organizations running 1 to 3 database platforms jumped from 57% in 2023 to 74% in 2025. Organizations running 4 or more platforms dropped from 42% to 26% in the same period. Organizations running a single platform climbed from 21% to 26%.

That’s a real move toward consolidation in just two years. But it’s not just about the databases themselves. It’s about everything that comes with them.

According to the same Redgate report, cost concerns doubled year over year. Licensing concerns tripled. Security concerns doubled. And here’s the one that resonates most with me: the challenge of finding and retaining people who actually understand your database portfolio jumped from 38% of organizations citing it in 2024 to 57% in 2025.

That last number is the one worth sitting with. The top operational headache isn’t even technical anymore. It’s people. You can’t hire enough database experts to keep seventeen different systems running properly. You can’t train your team fast enough. And you definitely can’t afford the salary premiums for specialists in every obscure database technology you’ve adopted.

We’ve Seen This Movie Before

This isn’t new. Technology goes through predictable cycles, and we’ve watched this one play out in other domains.

Look at filesystems. In the early days of computing, there were dozens of them: UFS, ext2, ReiserFS, FAT32, NTFS, HFS, and on and on. Each had defenders. Each had use cases where it was genuinely superior. But over time, a few dominant players emerged, and the long tail of specialized filesystems faded into obscurity or niche use.

Why? Because the marginal benefit of a specialist filesystem for a particular workload didn’t justify the operational complexity and the friction it created in the broader ecosystem. The “good enough” solution that integrated cleanly with everything else won out.

Databases are following the same curve.

The 2010s saw us climb the peak of proliferation. NoSQL was going to replace SQL. Document stores were the future. Graph databases were essential. Each innovation was real. These technologies genuinely solved problems that SQL couldn’t handle well. But then organizations started asking: “What does this cost us?”

The answer surprised no one who had been paying attention.

The Consolidation is Already Underway

The shift toward 1 to 3 dominant platforms isn’t accidental. It’s pragmatic. Enterprises are making conscious choices to standardize.

In some cases, that means standardizing on PostgreSQL, which has gotten significantly better at handling workloads it traditionally didn’t own, including analytics, JSON, time-series, and search. In other cases, it means standardizing on managed cloud databases from their cloud provider. In others, it’s a mix: a primary transactional database and one or two specialized platforms for workloads that genuinely require them.

The key shift is that the decision is now strategic rather than reactive. Instead of adding databases because a team wanted to try something new, organizations are asking harder questions: “Can our primary database handle this? If not, do the costs of adding a new system, in money, in operations, in hiring, in security, actually justify the performance benefit?”

Often, the answer is no.

NetApp’s 2021 Cloud Efficacy Report flagged this pattern emerging well before the Redgate numbers confirmed it: organizations underestimated the operational complexity of managing multiple specialized systems in cloud environments. The cloud made it easy to spin up a new database. It did nothing to make that database easier to run well.

What This Means Going Forward

The database market is consolidating. The data makes that clear. But consolidation doesn’t mean going backward to the monolithic database days of the 90s. It means getting smarter about when specialization actually matters.

The databases that survive and thrive won’t be the ones optimized for a single use case. They’ll be the ones that can handle multiple workloads well enough, integrate cleanly into modern ecosystems, don’t require hiring a specialist to operate, and give you options to scale without forcing you to add another system to your stack.

The question for the 2020s isn’t “What specialized database should I use for this workload?” It’s “Which of my core platform bets can handle this, and how do I optimize within that ecosystem?”

That’s a different conversation entirely. And it’s one the industry is finally having.

The sprawl era is ending. The strategy era is beginning.


This is the first post in a four-part series on database consolidation and what it means for data architecture. Next up: Why Cassandra Is Winning the Consolidation Game. The series continues with posts on AI-native infrastructure and a forward look at where this all lands over the next decade.