Graphs are complicated, in a good way. When we’re at school (unless you happen to be a mathematics whizz), the first time students are driven to start “graphing out” correlations and trends, that lesson is always one of the steeper learning curve experiences in our primary education experience. So it is with graph databases i.e they’re more complicated, in a good way, because they offer us a chance to trace relationships between multiple points and create a more enriched data entity, product or service at the end of the day.
As explained before here, graph database theory combines “nodes” in the form of people, places, products or things along with “edges”, the representative relationship values that describe what or how one thing is related to another… and also “properties”, which allow us to add additional contextual information to either an edge or a node.
If Teresa (a node) went to a pet shop (node) in Maryland (property) and paid for (edge, action) a puppy (node), then we might want to know that the puppy is six weeks old (property) and cost $200 (property) when she bought it at noon on Tuesday (property) and so on.
Because graph databases allow us to do more and know more, they enable us to build knowledge graphs that can organize information that might otherwise be too complex and convoluted for a traditional database to handle competently. They’re also used extensively in financial trading scenarios, recommendation engines and in fraud detection to help uncover hidden relationships in transactional data.
Graph Database Vendor Marketplace
Among the most vocal vendors in this marketplace are Neo4j, ArangoDB and OrientDB. Also of note is JanusGraph, a distributed graph database built to handle billions of vertices and edges, Dgraph, which bids to serve high-performance jobs, Stardog with its semantic reasoning abilities and NebulaGraph, also open source and also high performance. Among the tech behemoths, there’s Amazon Neptune, Google with its simply named Knowledge Graph service and Salesforce has Einstein Knowledge Graph and MuleSoft, GraphQL a data query language, that allows users to connect with application programming interfaces for graph-like data services. Similarly, Microsoft Graph is not a graph database in and of itself; it offers API connections to graph-type data intelligence in other Microsoft services.
Contextual exposition done then, in this age of AI, are graph databases getting any easier to use? Andreas Kollegger, lead for generative AI innovation at Neo4j says yes.
He’s rational about the progression though and explains that some still perceive graph as a domain for specialists; this is because they regard it as a technology for developers who can write Cypher queries (a declarative query language specifically designed for querying and updating graph databases) and for those who can manage extract, transform and load pipelines and piece together disparate datasets to create something meaningful.
Developers Have Been Gatekeepers
“Historically, this perceived lack of ‘accessibility’ wasn’t just about query languages. Even Cypher, which is designed to be more readable than SQL, requires understanding nodes, relationships and pattern matching,” said Kollegger. “It’s more intuitive than raw JOINs, but not exactly self-service for the average business user. A simple pattern like MATCH (customer)-[:BOUGHT]->(product) can still be a barrier if you don’t think in graphs. This has meant that developers became the interpreters. Queries were crafted, tweaked and explained to business analysts, but despite good intentions, that dynamic left software engineers in a familiar role: gatekeepers.”
It’s not unreasonable to say that progress has been gradual. Even with the rise of visual query builders and dashboard integrations, developing an understanding of graphs (let alone building them) still often meant learning the underlying model behind them or relying on someone who had. That’s starting to change and not just incrementally.
Welcome To Democratized Graph
“We’re entering a phase where the democratization of graph technology is becoming tangible. Advances in tooling mean users can work with relationships in their data without needing to write a single line of Cypher (or even know what Cypher is) now,” said Kollegger, speaking to press and analysts this month in London. “Ready-to-run algorithms, visual outputs and drag-and-drop workflows are replacing command lines and syntax trees. The ability to project subgraphs from familiar formats like spreadsheets or Pandas data frames without ETL gymnastics removes another long-standing barrier, one that frees up developers and opens the door to faster, more inclusive analysis.”
NOTE: A Pandas DataFrame is a 2-dimensional, tabular data structure in the Python Pandas library, designed for working with structured data, much like a spreadsheet or a SQL table.
Crucially, the shift that Kollegger talks about doesn’t dumb down the technology. It alleviates the complexity and only shows users what’s useful for the task at hand. If a businessperson wants to understand customer churn risk, they can run a community detection algorithm without having to write a query. If they need to uncover supply chain bottlenecks, the user can follow the relationships visually and apply similarity metrics with a click.
Kollegger says the shift from using SQL query language to this kind of business-level semantics (asking a graph database for an insight, without having to learn code) is not just a shift in language; it’s a forward shift in thinking. Where traditional data models assume structure, graphs assume relationships. Similarly, says Kollegger, semantics emerges from context, rather than content… but that context has historically lived in code, not conversation. Thanks to AI, that’s changing i.e. natural language reasoning maps smoothly to graphs and agentic memory itself often works the same way, with key ideas linking to related ones. It’s not just about retrieving memories but rebuilding them, like our own minds do, based on association.
Graphs Are How Humans Think
“Thinking in graphs may seem like a new way of working, until we realise it’s how we already think,” enthused Kollegger. “Of course, democratization doesn’t need to mean chaos. With greater accessibility comes a greater need for governance and here again, graphs offer an edge. Their structure encodes metadata and lineage in a way that helps enforce policy without getting in the way of exploration. Access controls can be fine-grained and context-aware because the context isn’t bolted on. It’s native.”
He further states that the role of the developer isn’t disappearing, but it is shifting.
Kollegger assures us that developers are no longer the only ones who can build out graph structures, they’re increasingly part of a broader ecosystem where analysts, product teams and business users can run graph-powered workflows themselves, gaining faster answers to complex questions without waiting on technical support.
“As tooling becomes more intuitive and data more accessible, the promise of graphs is no longer bound by syntax or specialism. It’s embedded in how we approach connected thinking across teams, tools and decisions,” he concluded.
The moves afoot here aren’t just about speed of operations (in the business team, or the developer team, or elsewhere) if they are embraced the right way. The Neo4j team say that this is “a fundamental shift in the culture of the developer organization” in real terms. This is because when more people can ask better questions of connected data faster (and get meaningful, visual, intuitive answers), the organization starts to think in graphs and that means they can identify more connections between different corners of the business.
