Another reason to use graphs

In May 2012 Google announced the Knowledge Graph. “Things, not strings” was the line. Search results got that panel on the right with the facts about a person or a place, and a lot of people outside universities heard the words “knowledge graph” for the first time.

I think that announcement did more for graph databases than any graph database ever did. It made the idea easy to explain: some data is mostly connections, and storing connections as rows in a join table and then joining five times to answer a question is a strange way to live.

The databases

Neo4j was already around in 2012, but it felt like it grew up between 2012 and 2014. Cypher, its query language, started to look like something you could show a colleague without apologising. You write a little ASCII picture of the pattern you want, (a)-[:KNOWS]->(b), and the database goes and finds it. I still think that is the best idea in the whole field. Neo4j 2.0 came out at the end of 2013 with labels on nodes and Cypher as the main way in, and that’s roughly when it stopped being a curiosity.

The other camp was Titan, a distributed graph database that sat on top of Cassandra or HBase and spoke Gremlin. The company behind Titan got bought and the project went quiet. In 2017 it was forked as JanusGraph under the Linux Foundation. Gremlin itself comes from Apache TinkerPop and works differently: you start somewhere and walk. g.V().has('name','savorg').out('cooked'). Some people love it. I find Cypher easier to read the next morning, but I get why the TinkerPop people wanted a language that runs the same way on any graph engine.

Then Amazon showed up. Neptune was announced at the end of 2017 and went generally available in 2018, speaking Gremlin and SPARQL, with openCypher added later. That’s about when graph stopped being a startup thing. If AWS has a managed version, procurement will sign it.

There were always two graph worlds that barely talked. RDF, SPARQL, ontologies, triple stores. It is older and more rigorous, and it is where the semantic web people live. Wikidata launched in late 2012 and it is a public example. The property graph people (Neo4j, Titan, later everyone) thought triples were awkward. The RDF people thought property graphs were toys without a schema. Both were a bit right. In 2024 the ISO GQL standard was finally published, a proper standard query language for property graphs, so that side now has what SQL gave relational databases decades ago. I don’t know anyone writing pure GQL yet, but it exists.

GraphQL is not a graph database

I have to say this once. Facebook open-sourced GraphQL in 2015. It is a query language for APIs. A client asks a server for exactly the fields it wants, and the shape of the response matches the shape of the question. It has “graph” in the name because your API’s types point at each other. It describes an API, without choosing how the server stores or fetches its data. The name confused me at first.

Graphs meet machine learning

Around 2017 I started hearing much more about neural networks over graphs. Graph convolutional networks first, then a wave of variants within a year or two. The pitch: a node’s representation should depend on its neighbours. Pinterest used a version of this for recommendations at serious scale. For a while every ML conference had a graph track and every graph database vendor had a “graph data science” product.

Honestly, I think most companies that bought a graph database in that period wanted a knowledge graph and had no plans for machine learning. The enterprise knowledge graph became its own category: connect your products, your customers, your suppliers and your documents into one structure and query across it. Banks used it for fraud rings, because fraud is literally a pattern of connections. Pharma used it for drug and gene relationships. A lot of these projects were expensive and a lot of them quietly died, because getting a whole company to agree on an ontology is mostly a political problem.

That sketch is the whole data model. Labelled nodes and typed edges, with properties on either. It fits on a napkin, which is why people like it and also why it gets messy: nothing stops you from inventing a fourth kind of “owns” edge on a Friday afternoon.

Vectors, then graphs again

Then 2023 happened. Large language models needed a way to look things up, and everybody built retrieval on top of vector search. For about a year the graph people looked worried. Embeddings don’t care about your carefully modelled edges.

It didn’t last. Plain vector retrieval is good at “find me chunks that sound like the question” and bad at “how are these two things related”, and the second kind of question is what people actually ask. Microsoft Research published GraphRAG in 2024: use a language model to pull entities and relationships out of documents, build a graph, summarise the communities in it, and then answer questions from the graph and those summaries instead of only comparing vectors. Graph and vector search started turning up together more often. I like being able to use either when a question needs it.

By 2025 the thing people were building graphs for was memory. An agent that runs for weeks needs to remember that this user prefers trains to planes, and that this decision was made after that meeting. A flat list of past messages is a bad way to store that. I find a graph with timestamps easier to reason about for those connections.

So fourteen years later the Knowledge Graph idea from 2012 is back, except now the thing reading the graph is a model instead of a search results page. I find that quite funny. The hard part is still what it was for the enterprise projects: deciding what the nodes are.