LDBC to GDC: A Landmark Shift in the Graph World

The recent Linked Data Benchmarking Council (LDBC) event was more of a landmark meeting than a routine gathering for several reasons.  But, even if you don’t know who the LDBC are, it still matters to anyone working on graphs.

The Linked Data Benchmark Council has, for over a decade, been the quiet force behind much of the progress in graph technology. Their mission is deceptively simple: to design, maintain, and promote standard benchmarks for graph data management systems. But benchmarks are more than performance charts, they create a shared language for vendors, researchers, and practitioners. Without them, it’s almost impossible to measure progress, compare systems fairly, or even agree on what “good” looks like in terms of scalability, query performance, or usability. LDBC has essentially provided the scaffolding that allows the graph ecosystem to grow with credibility and accountability. For those of us working in this space, that work is invaluable; it keeps vendors honest, guides researchers toward real-world relevance, and gives practitioners confidence in their technology choices.

The September 6th meeting wasn’t just about the 18+ talks packed into a single day, or the healthy mix of academic researchers, engineers, and industry practitioners sharing a room. It was about a collective sense that something is shifting in the graph world. For the first time, I could feel the boundaries of what used to be a niche field expanding outward, merging into the broader world of data systems and enterprise infrastructure.

From LDBC to Graph Data Council (GDC)

One of the defining announcements of the day was the decision for the Linked Data Benchmarking Council (LDBC) to rebrand as the Graph Data Council (GDC). On the surface, it might sound like a simple name change. But the weight of it is bigger. LDBC has been, for years, the quiet backbone of how we think about measuring and comparing graph technologies. Benchmarks, after all, are the unseen scaffolding of progress. You don’t always notice them, but they shape what developers prioritize, what researchers validate, and what vendors claim in their product sheets.

So when Henry Gabb the Chair of LDBC opened the day with the announcement: “LDBC becomes GDC”, it felt less like retiring an acronym and more like an announcement of a bigger vision. The council isn’t abandoning its benchmarking roots; those standards and tests will remain under the LDBC trademarks and continue operating as they are. Legally, the organization still retains the LDBC name and trademark. Instead, the rebrand signals ambition. The graph world has grown beyond niche uses into a full ecosystem, and GDC is setting out to mirror that growth with new initiatives: training programs, synthetic data generation, and knowledge-sharing frameworks. (And I’m sure we’ll all hear more about this in the coming months!)

For me, it connected deeply with what we’ve been trying to do at GraphGeeks: not just build technology, but grow the understanding of graphs. Education and tools that demystify graphs are as crucial as the systems themselves. Seeing GDC thinking along similar lines gives me hope that the coming years won’t just be about better engines, but also about a stronger, smarter community.

Graph Technology: Between Flux and Integration

One of the most memorable talks of the day came from Max Latey, CEO of PinBoard Consulting, who spoke under the title “Graph Technology: A World in Flux.” What struck me wasn’t just his energy but the balance of optimism and pragmatism in his perspective.

He argued, convincingly, that while graph databases are evolving, the most significant growth might not actually happen inside graph databases themselves. Instead, we’re seeing a subtle but important trend: graph capabilities quietly being integrated into other data platforms. Think Oracle Graph, Google Spanner, Microsoft Graph, PuppyGraph or even extensions layered on columnar data lakes. These aren’t standalone graph systems; they’re data platforms absorbing graph features because the use cases demand it.

It’s a fascinating paradox. On the one hand, we celebrate innovation in purpose-built graph databases, engines, and query languages. On the other, we recognize that many practitioners don’t necessarily want a graph database, they want solutions to their problems. If their existing tools can handle graph-shaped data, that’s often enough. Max put it bluntly: people will use graphs to solve a problem, and then they’ll move on. The graph layer becomes invisible, embedded in workflows rather than showcased as “new tech.”

This doesn’t mean stagnation. Quite the opposite. It means the real opportunity for growth is under the hood, better query engines, faster graph processing, smarter graph-text interfaces like text2Cypher, text2GQL, or entirely new abstractions like GraphAr, the Apache-incubated project that reimagines graph data archiving much like Parquet did for tabular data.

The GQL committee’s work came up repeatedly too. With GQL version 2 on the horizon, there’s genuine excitement about integrating concepts like key and unique constraints, partitioning, views, and even information schemas features SQL users like myself have long taken for granted, into graph query language. Talks by Keith Hare (president of JCC), Alastair Green (vice chair of LDBC and lead of LDBC Extended GQLSchema (LEX) working group), and Stefan Plantikow (Principal GQL Editor) painted a future where GQL isn’t just a specialized query dialect but a first-class citizen in the database language family. 

But language alone isn’t enough; developers and analysts need the right tools to make those features usable in practice. That’s why I found Arthur Bigeard’s session, “GQL is Here: What Will the Experience Be?”; so compelling. As the founder of G.V(), his vision of building interfaces that feel as natural and familiar as SQL workbenches, but designed specifically for graphs, really struck a chord with me. Add to that the innovations in temporal graphs (like those presented by Fabian Murariu from Pometry) and you begin to see the ecosystem maturing on multiple fronts all at once. Graphs are no longer just experimental or niche; they’re starting to show up exactly where the world needs them, whether in fraud detection, knowledge graphs, recommendation systems, or the emerging frontiers of graph-augmented AI.

Looking Ahead: From Knowledge to Community 🤝

The rebranding of LDBC to GDC seems to acknowledge the tension of where graph technology is headed. It’s not enough to measure performance anymore. We need to cultivate skills, share patterns, and keep the community connected. That’s where I see GraphGeeks playing its part too: helping bridge the gap between technology and knowledge, between capability and understanding. One example is graphfaker, a project I started to lower the barrier for experimenting with graph concepts. By letting developers generate structured but synthetic graph datasets, graphfaker makes it easier to learn, test ideas, and prototype solutions without the overhead of sourcing real-world data.

While walking to the train station with my friend Arthur, I noticed the conversations of the day were still ringing in my head, and I couldn’t shake the sense that we’re standing at the edge of something. Graphs are no longer the underdogs. They’re not shouting to be noticed. Instead, they’re becoming the quiet infrastructure threading through data systems, applications, and even AI pipelines.

Maybe that’s the most exciting part: graphs don’t need to prove themselves anymore. They’re already here, reshaping how we think about data. And with GDC taking the baton from LDBC, with projects like GraphAr emerging, and with GQL’s roadmap expanding, the ecosystem is not just alive, it’s restless, ambitious, and forward-looking.

For me, the LDBC (ahem, GDC) meeting wasn’t just an event. It was the beginning of an era, one we at GraphGeeks get to help write. And that, more than anything, is what makes me look forward to the next gathering.

Thank you so much Gabor Szarnyas for having us. 

-Dennis Irorere, Data Engineer and GraphGeeks Director of Innovation