Querying data where it lives: The architectural shift redefining graph technology

For many organisations, adopting graph technology has been challenging. Copying data into a graph database, keeping two versions in sync, building a pipeline that breaks the moment a schema changes upstream. The overhead is real, and it's kept some organizations on the sidelines of graph technology altogether. Now, a different path exists: finding out how your data connects without moving it first.

This approach has a name: zero ETL. Memgraph Zero, PuppyGraph, Neo4j Aura Graph Analytics, Google's Spanner Graph, and BigQuery Graph are all graph processing engines built on it, designed to query data in place just as enterprise data spreads across more systems than ever.

But the shift raises a real question: does this replace dedicated graph databases, or just sit alongside them? Where do these engines genuinely win, and where do they hit a wall?

To find out, we asked four people building and living inside this shift: Alan Brown, CTO at Aptitude Global; Amy Hodler, founder of GraphGeeks and co-author of O'Reilly's Graph Algorithms; Josep Tarruella, co-founder at Graph Everywhere; and Marko Budiselić, CTO and co-founder of Memgraph. What follows is their take on where graph processing engines are headed, and what they'd still leave to a dedicated graph database.

Dedicated graph databases earn their place, and for a range of use cases, nothing else performs the same way. But as enterprise data infrastructures have grown, a pain point has become harder to ignore: moving data into a graph database at scale can be expensive, time-consuming, and in some cases simply not possible.

At very large data volumes, copying data into a dedicated graph database can become impractical. As Marko Budiselić puts it: "There are a lot of large datasets which can't be moved in any system." This isn't a criticism of the technology itself, but a description of what happens when data volumes outgrow the pipeline designed to feed it.

Most enterprises have spent years consolidating their data into cloud lakehouses and warehouses, and that consolidation was expensive and slow. Asking those same organizations to copy their data again into a dedicated graph store runs into what Alan Brown calls ETL fatigue, a reluctance to create yet another copy of the data and pile more complexity onto a data estate that's already grown large. By the time the graph conversation starts, the appetite for another data migration may already be gone.

That dynamic plays out repeatedly, according to Josep Tarruella: "The conversation often becomes less about the value of graph analytics, which is widely recognized, and more about the total cost of adopting it at scale." Teams that understand graph and want to use it find themselves defending the infrastructure bill rather than the analytical value. That's where the adoption conversation tends to stall.

Zero ETL for graph means running graph queries directly against data in its existing location, without extracting, transforming, or loading it into a dedicated graph store first. This is the approach the current generation of graph processing engines is built around. The graph intelligence comes to the data, not the other way around.

What makes this workable day to day is the ability to switch query paradigms without switching data infrastructure. Alan Brown points to this as the practical advantage: teams can move between SQL-based and Cypher-based queries over the same data depending on the use case, which he calls "a much easier sell to any organization than standing up a graph database from scratch." Teams keep the infrastructure they already trust and just change the query language sitting on top of it, a smaller ask than rebuilding the data layer from the ground up.

Organizations spent years and significant budget moving their data into modern analytical platforms, standardizing around a single lakehouse layer. Graph processing engines that sit on top of that existing infrastructure don't ask them to undo any of it. Alan Brown makes the operational case clearly: adding a graph processing engine to infrastructure that already exists is a comparatively smaller investment. It comes without the usual costs of a new system:

• No duplicate data to maintain
• No additional model requiring synchronization
• No separate platform to operate

For teams already stretched across multiple systems, that reduction in overhead matters as much as the analytical capability itself.

Amy Hodler points to another operational problem, less about the price tag and more about what breaks along the way: "We want to query data where it lives instead of building fragile pipelines to move it." Pipelines break at the worst moments, usually when a schema changes upstream or a source system gets upgraded without warning. Querying without a traditional copy pipeline removes one important failure point: the synchronization process between the source data and a separate graph store.

A different kind of pressure is coming from AI, according to Josep Tarruella. As organizations build AI and agentic applications, they increasingly want "graph reasoning capabilities without redesigning their existing data architecture," and zero ETL is one way teams are getting there: running graph processing near where the data already sits reduces data movement, sync effort, and operational complexity, making graph more accessible to teams that might not have considered a dedicated platform before. Cost, reliability, and now AI adoption are pulling in the same direction, three separate pressures converging on the same architectural choice.

Zero ETL graph processing doesn't replace a dedicated graph database, it complements it. Which one fits depends on what the workload actually asks of the system, how deep it needs to query, how fast it needs to respond, how much it needs to hold steady under pressure.

Amy Hodler has a clear picture of where zero ETL earns its place: "Zero ETL wins for rapid prototyping, data discovery, and simple 3-5 hop queries…which is actually a lot of what businesses first want and need." That covers most of what organizations need when they're starting out, for exploration, for early-stage use cases, for teams testing whether graph adds value to their stack.

That advantage narrows as queries get more demanding. Hodler points specifically to deep, multi-hop traversal as a limitation: if a zero ETL engine has to translate a 10-hop traversal into hundreds of distributed SQL joins, she argues, it can hit a structural wall compared with a native, in-memory graph store. Whole-graph queries such as betweenness centrality present a different challenge: they still need to touch an entire set or subset of the data, even when the graph is virtual.

Workloads built around constant and high-speed writes hit a different wall. Alan Brown names latency as the dividing line: "For use cases that require high volumes of low-latency writes in particular rather than reads or traversal, where the gap is narrowing, a graph database is still the best option." Fraud detection is a clear case in point: transactions have to be caught, checked, and cleared or blocked within milliseconds, and that's exactly the kind of write-heavy, time-critical workload where a dedicated graph database keeps its edge.

Josep Tarruella draws the line around strategic intent: dedicated graph databases hold their advantage whenever the graph itself becomes a strategic operational asset, not just an analytical add-on. The use cases he points to as the clearest examples:

• Fraud detection
• Knowledge graphs
• Network management
• Customer intelligence
• Investigative platforms

Across these examples, the common requirements are:

• Relationships that need to persist and stay current
• Consistency that holds under continuous updates
• Queries fast enough to support real operations, not just analysis after the fact

None of this puts the two approaches in competition with each other. Alan Brown compares it to a shift the data world has already been through: "There's definitely still room for graph databases, in the same way there's still room for traditional relational databases despite the popularity of data lakehouses." A dedicated store and a zero ETL layer can sit in the same stack, serving different parts of the same business, without either one becoming obsolete. The right architecture comes down to the shape of the workload sitting in front of you, how deep the queries run, how fast the writes need to land, and whether the graph has to persist or just needs to be visible for a moment.

As AI agents take on more enterprise work, a new demand is emerging: giving agents access to information across an organization's distributed data, while allowing the knowledge they build to evolve over time. That's a different shape of workload than most graph infrastructure was originally built for.

Amy Hodler points to a specific limitation driving this: "Vector search has hit a wall; LLM agents need graphs to act as world models and context layers so they can actually reason without hallucinating." Vector search is good at finding things that resemble each other; by itself, it doesn't explicitly represent the relationships between entities, the paths connecting them, or how those relationships propagate through a system. Graph can fill that gap, and zero ETL graph gives agents that view without the underlying data being moved anywhere.

Marko Budiselić sees a related opportunity for AI agents in a centralized semantic layer over distributed data. Zero ETL can make that data accessible without requiring it to be moved into another system, while a semantic layer can provide agents with a centralized way to access it. As he puts it, having "the illusion that data is at one place" is convenient for agents because they can work through a single endpoint rather than accessing every source separately.

There's another piece to this: the feedback loop. Marko argues that agents should be able to incrementally incorporate new knowledge as they figure things out. In large systems, no single person or agent knows everything, so building the right schema or knowledge graph is an iterative process. A centralized feedback loop gives agents a better chance of refining that knowledge over time.

How the two approaches divide the work comes into focus in a picture Amy Hodler sketches: "Zero ETL engines could become AI's broad view. A virtual graph view across all corporate silos without moving data. Dedicated graph DBs become the AI's high-speed brain—handling the rapid reasoning loops and acting as the agent's real-time working memory." It's the same complementary architecture: broad access for exploration, dedicated infrastructure where speed and operational persistence matter.

Removing the need to move data doesn't remove every obstacle. Three still show up in practice: closing the gap between what teams know and what the technology can do, working with data that wasn't built for graph queries, and accounting for costs that go well beyond the license fee.

Before skill even enters the picture, there's a more basic gap. Marko Budiselić points to awareness itself as the first obstacle: "The main thing is education, because people are just not aware of the concept and especially not all the capabilities that are available." Getting started is hard mostly because of that learning curve, he says, not because of any limitation in the technology itself, and closing that gap is what he sees as the real work ahead: making graph "much easier, much faster, much more scalable."

Once organizations get past that first hurdle, the shortage shifts from awareness to hands-on expertise. Alan Brown is specific about where the gap sits: "There's a shortage of platform and infrastructure engineers with real experience architecting, deploying, and supporting production-grade graph databases at the data volumes enterprises actually need." That gap predates zero ETL and won't close because of it. Querying data in place still requires someone who understands both the graph model and the systems the data actually lives in.

Zero ETL removes the need to move data before querying it, but it doesn't fix the condition the data is in. Amy Hodler describes the underlying struggle: "The nightmare is getting messy, sparse, and siloed data into the right shape to ask 'graphy' questions." Leaving that data where it sits doesn't solve it either, since the problem was never really about location. If definitions don't line up across business units to begin with, querying in place just gets you, in her words, "a faster way to query garbage." The pipeline problem and the data quality problem are separate challenges, and zero ETL doesn't eliminate the latter.

License cost is the number every business case leads with, because it's the simplest one to point to. That simplicity is also what makes it misleading: it's only a fraction of what the technology actually costs. What actually gets counted once a project is underway goes well beyond that, according to Josep Tarruella: "This goes beyond licensing costs. It also includes data integration, infrastructure, operational overhead, learning new technologies and maintaining another production environment." Zero ETL doesn't necessarily eliminate that overhead; some of it shifts to other parts of the architecture.

Every signal points forward, whether that's more organizations reaching for graph, or processing engines gaining ground on the databases that came before them.

Alan Brown expects a shift in market share specifically: "I believe graph processing engines will keep growing in popularity and will eventually overtake traditional graph databases." In his view, more organizations have occasional, lightweight graph needs than run graph-native, high-throughput workloads at scale, so as more of that larger group adopts graph, processing engines may pick up the majority of new users by being the easier entry point. That popularity shift doesn't necessarily touch performance: dedicated graph databases can still outperform processing engines on the workloads they were built for. What changes, in his view, is how many organizations end up choosing one over the other, depending on their needs.

Josep Tarruella points to a different force behind the same trend: AI. As organizations build AI and agentic applications, he argues, the barrier to adopting graph keeps falling, and that's pulling graph analytics out of specialist territory and into standard AI and data science workflows.

Amy Hodler's closing idea goes a step further by leveraging hyperdimensional computing (HDC). By encoding graph structures (nodes, relationships, and attributes) directly into high-dimensional hypervectors, HDC bridges symbolic graph reasoning with vector-based AI. Rather than forcing a choice between a traditional graph database and a vector engine, HDC handles structural queries directly through hypervector arithmetic. The approach works on standard hardware today, and eventually when paired with ultra-low-power neuromorphic processors, it enables lightweight, decentralized agentic AI at the source.

HDC is proof the architecture conversation is far from settled. That uncertainty doesn't change what's already working: zero ETL is already addressing the cost, data-movement, and AI-adoption pressures laid out earlier, using infrastructure enterprises already have. Whatever graph architecture looks like next, this is what it's built on today.

Whether the data sits in a dedicated graph database or stays in a lakehouse queried by a zero ETL engine, some questions aren't answered by the query result itself, they're answered by seeing the structure laid out. Investigating a fraud ring, tracing a cyberattack path, or mapping how an organization connects often comes down to seeing the shape of the network. That's where the Linkurious platform comes in: a tool built to visualize and investigate connected data so analysts can spot patterns and act on them without writing a query first.

For teams building their own graph-powered applications, Ogma, Linkurious' JavaScript visualization library, lets developers render large-scale, interactive graph visualizations directly inside their own product.

If your team is working with connected data and wants a way to actually visualize it, contact us to find the right fit.