Alberto D. Mendoza

My Thoughts on The Next Great Database Migration

---

I was having coffee with a Chief Data Architect last week, and he mentioned his recent conversation with a CTO. To paraphrase his word: “We’re spending $2.1 million to migrate our core systems to a graph database. My board thinks I’ve lost my mind.”

I’ll be keeping an eye on how it plays out for that Company. Nonetheless, that conversation stuck with me because it crystallizes something I’ve been thinking about for months if not years. We’re about to witness what might be the most significant shift in enterprise data architecture since the rise of SQL. The question is, will Enterprises approach it the right way?

My Own Database Journey, and Where I Got It Wrong

Let me back up a bit and tell you my own story with databases, because it’s probably familiar to many of you.

As a Systems Analyst managing a sprawling technical portfolio, I was obsessed with documentation. I didn’t call it architecture back then—I just knew we needed reliable, up-to-date information about our systems. That’s when I discovered graph databases through Neo4j and an Archi plugin.

I went down the rabbit hole hard. Conferences, books, graph algorithms. I built my own repository, modeled everything as a labeled property graph, used shortest-path algorithms for impact assessments. It was beautiful, elegant, and incredibly sophisticated.

I quickly realized something that stopped me in my tracks: I was so focused on building the perfect database architecture that I’d forgotten why I needed the data in the first place, but then it hit me. It’s all about semantics!

The Numbers Don’t Lie (But They Don’t Tell the Whole Story Either)

Here’s what market pundits were telling us a few years ago: “Use of graph databases will explode.”, “We’re looking at a market that expanded from $2.57 billion in 2022 with a projected growth rate of 21.9% annually through 2030.”, “Graph technologies will be used in 80% of data and analytics innovations by 2025, up from just 10% in 2021.” (all Gartner predictions).

But here’s the reality check: actual enterprise adoption sits at just 4-6%, according to the same Gartner research. Most implementations are still driven by data scientists, not mainstream business users.

That gap between potential and reality? That’s where the real story lives.

I See 14 Million Possibilities

I’m no Dr. Strange who could see 14 Million possibilities, but I’ve been tracking this space long enough to see three distinct paths emerging (warning: wear your tin foil hats):

The Gradual Evolution (70% probability) Most enterprises will slowly add graph capabilities alongside their existing relational systems. Think Microsoft, Oracle, and IBM integrating graph features into their existing platforms. It’s safe, incremental, and probably smart.

The Open Standards Revolution (20% probability) Major cloud providers converge around open standards like the emerging Graph Query Language (GQL) finally published by ISO. This would mirror what happened with SQL in 1989—when standardization unleashed massive adoption.

The Fragmented Future (10% probability) Multiple competing proprietary ecosystems persist, each optimized for specific use cases. High switching costs, vendor lock-in, innovation stagnation.

But here’s what bothers me about all three scenarios: they’re still focused on the technology, not the understanding.

What I’m Really Talking About (And It’s Not Databases)

Remember that CTO I mentioned? When I dug deeper into the story, the real issue wasn’t about graph vs. relational databases. It was about the organization’s inability to understand the relationships in their own data.

They probably had customer data scattered across seventeen different systems. Sales couldn’t see the complete customer journey. Marketing was running campaigns based on incomplete pictures. Product development was building features nobody wanted because they couldn’t connect user behavior to business outcomes.

The graph database wasn’t the solution—it was just a tool that might help them see what they’d been missing all along, and this reminds me of something I learned from Svyatoslav Kotusev’s work on Enterprise Architecture: tools should support your practice, not define it. (also, that most EA work isn’t about modeling—it’s about strategic communication, alignment, and decision-making… but that’s on the other blogpost).

The Real Migration

The companies that will succeed in this transition aren’t necessarily the ones with the best database technology. They’re the ones that understand what they’re trying to accomplish.

Take the financial services companies using graph databases for fraud detection. They’re not succeeding because graphs are inherently better at detecting fraud. They’re succeeding because they finally have a way to visualize and understand the complex relationships that fraudsters exploit.

Or consider the retail companies optimizing their supply chains with graph technology. The breakthrough isn’t the database—it’s the insight that supply chains are networks, not linear processes.

The AI Factor, And Why This Matters More Than You Think

Here’s something that’s been nagging at me: I’m talking about database transitions at the exact moment when AI is looking to reshape how businesses operate, and you know why? Because AI thrives on semantic data.

Large Language Models are fundamentally better at understanding and reasoning with graph-structured, semantic data than they are with traditional relational schemas. When your data is modeled as entities and relationships (the way humans naturally think) AI can more easily understand context, infer connections, and generate insights.

Think about it: when you ask ChatGPT a complex business question, it’s not running SQL joins in its head. It’s reasoning through relationships and connections, much like a knowledge graph.

This has massive implications for enterprise data strategies. Companies building knowledge graphs aren’t just improving their data architecture, they are creating foundations for unleashing AI-centered systems. When your customer data, product information, and business processes are semantically connected, your AI initiatives can leverage that rich context in ways that flat relational tables simply can’t support.

The businesses getting this right are building what dare I call “AI-native data architectures”, where the data model itself becomes a competitive advantage in the age of artificial intelligence.

Capital Markets Have Woken Up

The investment community has clearly noticed this trend. Within my small LinkedIn circle (probably self-selection bias), I’m seeing major consolidation plays that signal something significant is happening in the semantic data space.

Just this year, ServiceNow announced its acquisition of data.world, a cloud-native data catalog and governance platform built on knowledge graph technology. This came after their $2.85 billion acquisition of Moveworks, showing ServiceNow is betting big on what everyone is calling “agentic AI” and they need semantic data foundations to make it work.

As Gaurav Rewari, ServiceNow’s SVP of data analytics, put it: “The path that goes to that agentic AI heaven often goes through data hell.” They’re not just buying technology—they’re buying the infrastructure needed to make AI systems actually useful.

Even more telling was the merger of Semantic Web Company and Ontotext to create Graphwise in late 2024. These are two of the most established players in the semantic technology space, combining their PoolParty knowledge management platform with GraphDB. As Atanas Kiryakov, Graphwise’s president, explained: “Knowledge graphs are like a GPS for AI and large language models. They guide AI models with precision and context to ensure trustworthy, explainable outputs.”

The timing isn’t coincidental. Gartner predicts that “the data fabric must evolve to manage multimodal data for grounded and guardrailed GenAI applications in the enterprise. Without including unstructured and semistructured data management into data fabric processes, the GenAI experience will continue to have major hallucination problems.”

Translation: companies that can’t semantic their data are going to have AI systems that make stuff up.

What This Means for Your Organization

So where does this leave those of us making decisions about database architectures?

First, resist the temptation to lead with the technology. Start with the business problem. What relationships in your data are you failing to understand? Where are you making decisions with incomplete pictures?

Second, experiment strategically. Pick use cases where relationship-heavy data provides clear business value. Don’t migrate your entire enterprise because someone at a conference showed you a pretty graph visualization.

Third, invest in understanding, not just tools. The most sophisticated graph database in the world won’t help you if your organization doesn’t know how to think in terms of relationships and networks.

Fourth, consider your AI strategy. If you’re planning enterprise AI initiatives, semantic data models might not be optional—they might be essential for competitive advantage.

The Questions That Actually Matter

Instead of asking “Should we migrate to graph databases?” try these:

• What relationships in our data are we currently blind to?
• Where are we making business decisions with incomplete information?
• How might better understanding of data connections change our strategy?
• What would it mean for our competitive advantage if we could see patterns our competitors miss?
• How will our AI initiatives benefit from semantically-rich data models?

A Final Thought

That Chief Data Architect I mentioned, his company is sitting mere feet away from a €90 million EU project to establish an AI factory, which will be located at Sofia Tech Park, in Bulgaria.

Their success won’t be measured in query performance or storage efficiency. It’ll be measured in whether they unlock science and businesses new ways of understanding, and whether that understanding gives them an edge in an AI-driven marketplace.

The great database migration is going to happen, but it will not be about databases. It will be about understanding. And in the end, that might be the most important quarter-inch hole everyone needs to drill.