High Performance And Low Overhead Graphs With KuzuDB

Summary
In this episode of the Data Engineering Podcast Prashanth Rao, an AI engineer at KuzuDB, talks about their embeddable graph database. Prashanth explains how KuzuDB addresses performance shortcomings in existing solutions through columnar storage and novel join algorithms. He discusses the usability and scalability of KuzuDB, emphasizing its open-source nature and potential for various graph applications. The conversation explores the growing interest in graph databases due to their AI and data engineering applications, and Prashanth highlights KuzuDB's potential in edge computing, ephemeral workloads, and integration with other formats like Iceberg and Parquet.


Announcements

• Hello and welcome to the Data Engineering Podcast, the show about modern data management
• Data migrations are brutal. They drag on for months—sometimes years—burning through resources and crushing team morale. Datafold's AI-powered Migration Agent changes all that. Their unique combination of AI code translation and automated data validation has helped companies complete migrations up to 10 times faster than manual approaches. And they're so confident in their solution, they'll actually guarantee your timeline in writing. Ready to turn your year-long migration into weeks? Visit dataengineeringpodcast.com/datafold today for the details.
• Your host is Tobias Macey and today I'm interviewing Prashanth Rao about KuzuDB, an embeddable graph database

Interview

• Introduction
• How did you get involved in the area of data management?
• Can you describe what KuzuDB is and the story behind it?
• What are the core use cases that Kuzu is focused on addressing?
  • What is explicitly out of scope?
• Graph engines have been available and in use for a long time, but generally for more niche use cases. How would you characterize the current state of the graph data ecosystem?
• You note scalability as a feature of Kuzu, which is a phrase with many potential interpretations. Typically horizontal scaling of graphs has been complicated, in what sense does Kuzu make that claim?
• Can you describe some of the typical architecture and integration patterns of Kuzu?
  • What are some of the more interesting or esoteric means of architecting with Kuzu?
• For cases where Kuzu is rendering a graph across an external data repository (e.g. Iceberg, etc.), what are the patterns for balancing data freshness with network/compute efficiency? (e.g. read and create every time or persist the Kuzu state)
• Can you describe the internal architecture of Kuzu and key design factors?
  • What are the benefits and tradeoffs of using a columnar store with adjacency lists vs. a more graph-native storage format?
• What are the most interesting, innovative, or unexpected ways that you have seen Kuzu used?
• What are the most interesting, unexpected, or challenging lessons that you have learned while working on Kuzu?
• When is Kuzu the wrong choice?
• What do you have planned for the future of Kuzu?

Contact Info

• Website
• LinkedIn

Parting Question

• From your perspective, what is the biggest gap in the tooling or technology for data management today?

Links

• KuzuDB
• BERT
• Transformer Architecture
• DuckDB
  • Podcast Episode
• MonetDB
• Umbra DB
• sqlite
• Cypher Query Language
• Property Graph
• Neo4J
• GraphRAG
• Context Engineering
• Write-Ahead Log
• Bauplan
• Iceberg
• DuckLake
• Lance
• LanceDB
• Arrow
• Polars
• Arrow DataFusion
• GQL
• ClickHouse
• Adjacency List
• Why Graph Databases Need New Join Algorithms
• KuzuDB WASM
• RAG == Retrieval Augmented Generation
• NetworkX

The intro and outro music is from The Hug by The Freak Fandango Orchestra / CC BY-SA