If you’ve been using KuzuDB for graph queries, you already know: Kùzu Inc. was acquired by Apple in October 2025, the GitHub repository was archived, and the project is dead. Community forks like LadybugDB are early-stage experiments with no funding, no core team, and no roadmap. You need a production path forward — now.
The conventional wisdom was that Kuzu was unbeatable for graph analytics. Columnar storage, worst-case-optimal joins, C++ performance — the academic pedigree was real. So the assumption was always: if you’re migrating away from Kuzu, you’re trading analytical performance for other features.
That assumption is wrong. We benchmarked ArcadeDB against Kuzu on the LDBC Graphalytics benchmark — the industry-standard suite for graph analytics — and ArcadeDB is faster on every single algorithm. Not by a small margin. Up to 9x faster.
ArcadeDB vs KuzuDB: The Benchmark Results
These are the LDBC Graphalytics benchmark results on the same dataset and hardware. Lower is better:
| Algorithm | ArcadeDB | KuzuDB | Speedup |
|---|---|---|---|
| PageRank | 0.48s | 4.30s | 8.9x faster |
| WCC (Weakly Connected Components) | 0.30s | 0.43s | 1.4x faster |
| BFS (Breadth-First Search) | 0.13s | 0.86s | 6.6x faster |
| LCC (Local Clustering Coefficient) | 27.41s | N/A | Kuzu doesn’t support it |
| SSSP (Single Source Shortest Path) | 3.53s | N/A | Kuzu doesn’t support it |
| CDLP (Community Detection) | 3.67s | N/A | Kuzu doesn’t support it |
Results are fully reproducible — see the benchmark project on GitHub.
Let that sink in: the database that was supposed to be “OLAP-optimized for graph analytics” is 9x slower on PageRank and doesn’t even support three of the six standard graph algorithms. ArcadeDB’s new Graph OLAP Engine doesn’t just match Kuzu’s analytical capabilities — it demolishes them.
And ArcadeDB does this while also being a full multi-model database with OLTP support, five query languages, six data models, vector search, and a built-in MCP server for AI agents. Kuzu was graph-only, analytics-only, embedded-only.
What KuzuDB was
KuzuDB was an embedded OLAP graph database — it ran in-process, used columnar storage, and was designed for analytical graph queries. It was MIT-licensed, written in C++, and callable from Python, Java, Node.js, and Rust. The academic research behind it was solid (University of Waterloo), and for a while, the “DuckDB for graphs” positioning made it an attractive choice.
But “was” is the key word. The project is archived. The team is at Apple. And the benchmarks show that even its core value proposition — analytical graph performance — wasn’t as strong as the marketing suggested.
What ArcadeDB is
ArcadeDB is a multi-model DBMS — graph, document, key/value, full-text search, time series, and vector embeddings in a single engine. It runs as a server by default, though it can also run as an embedded Java library. It is fully open source under the Apache 2.0 license with a public commitment to never change it.
Here’s what you gain by migrating from Kuzu to ArcadeDB:
1. Faster graph analytics (proven by benchmarks)
The numbers don’t lie. ArcadeDB’s Graph OLAP Engine outperforms Kuzu on every LDBC Graphalytics algorithm that Kuzu supports — and runs three additional algorithms that Kuzu can’t. If you chose Kuzu for analytics, ArcadeDB is the upgrade, not the compromise.
2. Five query languages instead of one
Kuzu supported Cypher. ArcadeDB supports SQL, Cypher, Gremlin, GraphQL, and MQL (MongoDB-compatible). Your existing Cypher queries work as-is — ArcadeDB passes 97.8% of the OpenCypher TCK. But now you can also query the same data with SQL, expose it via GraphQL, or connect MongoDB-compatible applications.
3. Six data models in one engine
Kuzu was graph-only. ArcadeDB natively handles graph, document, key-value, time-series, vector, and full-text search — all in the same database. No ETL pipelines, no data duplication, no second database for your documents or embeddings.
4. Vector search and AI readiness
ArcadeDB ships with native vector search and a built-in MCP server that lets LLMs and AI agents query your database directly. This is the GraphRAG pattern — graph traversal + vector similarity + full-text search in a single query. Kuzu had experimental vector support; ArcadeDB has production-ready AI integration.
5. OLTP + OLAP in one database
Kuzu was OLAP-only — batch analytics, no concurrent writes, no real-time serving. ArcadeDB is ACID-compliant with full transaction isolation, designed for mixed OLTP + OLAP workloads. You can run your analytical graph algorithms and serve live application traffic from the same database.
6. Apache 2.0 with a no-change commitment
The Kuzu acquisition is a reminder: MIT license doesn’t protect you from your vendor disappearing. ArcadeDB is Apache 2.0, and we’ve been through this before — we built ArcadeDB after SAP acquired OrientDB and changed its trajectory. We publicly committed to never changing the license.
The full comparison
| Feature | ArcadeDB | KuzuDB |
|---|---|---|
| Status | Active, regular releases | Archived (Oct 2025) |
| License | Apache 2.0 | MIT (archived) |
| PageRank | 0.48s | 4.30s (8.9x slower) |
| BFS | 0.13s | 0.86s (6.6x slower) |
| WCC | 0.30s | 0.43s (1.4x slower) |
| LCC / SSSP / CDLP | Supported | Not supported |
| Data models | 6 (Graph, Doc, KV, TimeSeries, Vector, Search) | 1 (Graph) |
| Query languages | 5 (SQL, Cypher, Gremlin, GraphQL, MQL) | 1 (Cypher) |
| OLTP support | Yes (ACID, transactions) | No (OLAP only) |
| Vector search | Built-in | Experimental |
| MCP server (AI) | Built-in | No |
| Server mode | Yes | No (embedded only) |
| Deployment | Server, embedded, Docker, cloud | Embedded only |
The only tradeoff
There is one genuine tradeoff: ArcadeDB requires a JVM. If your stack is Rust, Go, or Python-native and you absolutely cannot tolerate a JVM dependency, ArcadeDB’s embedded mode won’t work for you. But the client-server architecture means your application code can be in any language — Python, Rust, Go, Node.js — connecting via HTTP API, Bolt protocol, or Gremlin drivers.
For the vast majority of Kuzu users, this isn’t a blocker. And given that ArcadeDB is faster, more capable, and actively maintained, the JVM dependency is a small price for a massive upgrade.
Getting started
# Docker (fastest start)
docker run --rm -it -p 2480:2480 -p 2424:2424 \
-e JAVA_OPTS="-Darcadedb.server.rootPassword=playwithdata" \
arcadedata/arcadedb
Open http://localhost:2480 and start querying with SQL, Cypher, Gremlin, or GraphQL. Your Kuzu Cypher queries will run as-is.
- Documentation: https://docs.arcadedb.com
- GitHub: https://github.com/ArcadeData/arcadedb
- Discord: https://discord.gg/arcadedb
Step-by-step migration guide: KuzuDB to ArcadeDB
This section walks you through the full migration process. The recommended path is: export from KuzuDB as CSV, translate the schema, then import into ArcadeDB.
Step 1: Export your KuzuDB database
KuzuDB’s EXPORT DATABASE command dumps everything — schema definitions and data files — into a directory.
import kuzu
db = kuzu.Database("./my_kuzu_db")
conn = kuzu.Connection(db)
# Export the full database as CSV with headers
conn.execute("EXPORT DATABASE '/tmp/kuzu_export' (format='csv', header=true)")
This creates:
/tmp/kuzu_export/
├── schema.cypher # CREATE NODE TABLE / CREATE REL TABLE statements
├── copy.cypher # COPY FROM statements (for re-import into Kuzu)
├── macro.cypher # Macro definitions (if any)
├── Person.csv # One CSV file per node table
├── Company.csv
├── Follows.csv # One CSV file per relationship table
└── WorksAt.csv
Open schema.cypher — this is your source of truth for the schema translation.
Step 2: Translate the schema to ArcadeDB
KuzuDB and ArcadeDB use different DDL syntax and type names. Here’s the mapping:
| KuzuDB | ArcadeDB |
|---|---|
CREATE NODE TABLE |
CREATE VERTEX TYPE |
CREATE REL TABLE |
CREATE EDGE TYPE |
PRIMARY KEY |
CREATE INDEX ... UNIQUE |
INT64 |
LONG |
INT32 |
INTEGER |
INT16 |
SHORT |
FLOAT |
FLOAT |
DOUBLE |
DOUBLE |
STRING |
STRING |
BOOLEAN |
BOOLEAN |
DATE |
DATE |
TIMESTAMP |
DATETIME |
KuzuDB schema example (from schema.cypher):
CREATE NODE TABLE Person(id INT64 PRIMARY KEY, name STRING, age INT64, registered DATE);
CREATE NODE TABLE Company(id INT64 PRIMARY KEY, name STRING, founded INT64);
CREATE REL TABLE Follows(FROM Person TO Person, since INT64);
CREATE REL TABLE WorksAt(FROM Person TO Company, role STRING, since INT64);
Translated ArcadeDB schema (SQL):
-- Create vertex types
CREATE VERTEX TYPE Person;
CREATE PROPERTY Person.id LONG;
CREATE PROPERTY Person.name STRING;
CREATE PROPERTY Person.age LONG;
CREATE PROPERTY Person.registered DATE;
CREATE INDEX ON Person (id) UNIQUE;
CREATE VERTEX TYPE Company;
CREATE PROPERTY Company.id LONG;
CREATE PROPERTY Company.name STRING;
CREATE PROPERTY Company.founded LONG;
CREATE INDEX ON Company (id) UNIQUE;
-- Create edge types
CREATE EDGE TYPE Follows;
CREATE PROPERTY Follows.since LONG;
CREATE EDGE TYPE WorksAt;
CREATE PROPERTY WorksAt.role STRING;
CREATE PROPERTY WorksAt.since LONG;
You can execute these statements via the ArcadeDB console, the HTTP API, or Studio.
Step 3: Start ArcadeDB and create the database
# Start ArcadeDB with Docker
docker run -d --name arcadedb \
-p 2480:2480 -p 2424:2424 \
-e JAVA_OPTS="-Darcadedb.server.rootPassword=your_password" \
arcadedata/arcadedb
Create the database and execute the schema:
# Create a new database via the HTTP API
curl -X POST "http://localhost:2480/api/v1/server" \
-u root:your_password \
-d '{"command": "CREATE DATABASE mydb"}'
Then execute each schema statement:
# Execute schema DDL
curl -X POST "http://localhost:2480/api/v1/command/mydb" \
-u root:your_password \
-H "Content-Type: application/json" \
-d '{"language": "sql", "command": "CREATE VERTEX TYPE Person"}'
Repeat for each type and property definition — or use a script (see Step 4).
Step 4: Import node/vertex data from CSV
Import vertices first, edges second. For each node table exported from KuzuDB, load the CSV into ArcadeDB.
Option A: Using the HTTP API with a script
import csv
import requests
ARCADEDB_URL = "http://localhost:2480/api/v1/command/mydb"
AUTH = ("root", "your_password")
def execute_sql(sql):
resp = requests.post(ARCADEDB_URL, auth=AUTH,
json={"language": "sql", "command": sql})
resp.raise_for_status()
return resp.json()
# Import Person vertices
with open("/tmp/kuzu_export/Person.csv") as f:
reader = csv.DictReader(f)
for row in reader:
sql = f"""INSERT INTO Person SET id = {row['id']},
name = '{row['name'].replace("'", "''")}',
age = {row['age']},
registered = '{row['registered']}'"""
execute_sql(sql)
# Import Company vertices
with open("/tmp/kuzu_export/Company.csv") as f:
reader = csv.DictReader(f)
for row in reader:
sql = f"""INSERT INTO Company SET id = {row['id']},
name = '{row['name'].replace("'", "''")}',
founded = {row['founded']}"""
execute_sql(sql)
print("Vertices imported.")
Option B: Using ArcadeDB’s SQL IMPORT DATABASE (for simple cases)
If your CSV has a straightforward structure, you can use ArcadeDB’s built-in importer:
IMPORT DATABASE file:///tmp/kuzu_export/Person.csv
WITH (vertexType = 'Person', commitEvery = 5000)
Option C: Using batch inserts for better performance
For large datasets, batch your inserts inside a single transaction:
curl -X POST "http://localhost:2480/api/v1/begin/mydb" -u root:your_password
# ... send multiple INSERT commands ...
curl -X POST "http://localhost:2480/api/v1/commit/mydb" -u root:your_password
Step 5: Import relationship/edge data from CSV
KuzuDB relationship CSV files include _from_ and _to_ columns containing the primary key values of the source and target nodes. Use these to create edges in ArcadeDB.
# Import Follows edges
with open("/tmp/kuzu_export/Follows.csv") as f:
reader = csv.DictReader(f)
for row in reader:
sql = f"""CREATE EDGE Follows
FROM (SELECT FROM Person WHERE id = {row['Person.id']})
TO (SELECT FROM Person WHERE id = {row['Person.id_1']})
SET since = {row['since']}"""
execute_sql(sql)
# Import WorksAt edges
with open("/tmp/kuzu_export/WorksAt.csv") as f:
reader = csv.DictReader(f)
for row in reader:
sql = f"""CREATE EDGE WorksAt
FROM (SELECT FROM Person WHERE id = {row['Person.id']})
TO (SELECT FROM Company WHERE id = {row['Company.id']})
SET role = '{row['role'].replace("'", "''")}',
since = {row['since']}"""
execute_sql(sql)
print("Edges imported.")
Important: The exact column names in Kuzu’s exported CSV depend on your schema. Check the CSV headers before writing the import script. Kuzu typically exports relationship CSVs with columns like from, to, or TableName.primaryKey for the source and target references.
Step 6: Create indexes for query performance
After all data is loaded, create indexes on properties you’ll use for lookups:
-- Already created unique indexes on primary keys in Step 2
-- Add additional indexes for common query patterns
CREATE INDEX ON Person (name);
CREATE INDEX ON Company (name);
Step 7: Validate the migration
Run validation queries to confirm data integrity:
-- Check vertex counts match KuzuDB
SELECT count(*) FROM Person;
SELECT count(*) FROM Company;
-- Check edge counts
SELECT count(*) FROM Follows;
SELECT count(*) FROM WorksAt;
-- Spot-check a known record
SELECT * FROM Person WHERE id = 1;
-- Validate a graph traversal
SELECT expand(out('Follows')) FROM Person WHERE name = 'Alice';
Compare these results against your KuzuDB queries:
// In Kuzu (for reference)
MATCH (p:Person) RETURN count(p);
MATCH ()-[f:Follows]->() RETURN count(f);
Step 8: Migrate your application queries
If you were using Cypher in KuzuDB, most queries will work in ArcadeDB with minimal changes. ArcadeDB’s Cypher support is OpenCypher TCK-compliant.
Queries that work as-is:
MATCH (p:Person)-[:Follows]->(friend)
WHERE p.name = 'Alice'
RETURN friend.name;
What to watch for:
- Kuzu-specific functions (e.g.,
list_extract,struct_extract) don’t exist in ArcadeDB. Replace them with ArcadeDB equivalents or standard Cypher. - Kuzu’s recursive path queries (
MATCH (a)-[:Follows*1..3]->(b)) work in ArcadeDB Cypher, but performance characteristics may differ for very deep traversals. - Schema queries like
CALL show_tables()are Kuzu-specific. In ArcadeDB, useSELECT FROM schema:typesor the Studio UI. - COPY FROM/TO does not exist in ArcadeDB Cypher. Use SQL
IMPORT/EXPORTor the HTTP API instead.
You can also use ArcadeDB’s SQL dialect, which supports graph traversal operators:
-- ArcadeDB SQL with graph extensions
SELECT out('Follows').name AS friends
FROM Person
WHERE name = 'Alice';
Key Takeaways
- ArcadeDB outperforms KuzuDB on every LDBC Graphalytics benchmark — up to 9x faster on PageRank, 6.6x on BFS — destroying the myth that Kuzu was the analytics champion.
- Kuzu doesn’t support 3 of the 6 standard LDBC algorithms (LCC, SSSP, CDLP). ArcadeDB supports all of them.
- ArcadeDB adds 5 query languages, 6 data models, OLTP support, vector search, and AI/MCP integration — capabilities Kuzu never had.
- KuzuDB is archived and abandoned. ArcadeDB is actively developed under Apache 2.0 with a public commitment to never change the license.
- Your Kuzu Cypher queries work as-is on ArcadeDB (97.8% OpenCypher TCK compliance).
You’re not downgrading by leaving Kuzu. You’re upgrading — to a database that’s faster at analytics, broader in capabilities, and actually maintained.
Frequently Asked Questions
What is the best KuzuDB replacement in 2026?
ArcadeDB is the best KuzuDB replacement. It outperforms Kuzu on every LDBC Graphalytics benchmark (up to 9x faster on PageRank), supports Cypher queries as-is, and adds five more query languages and six data models — all under Apache 2.0 license.
Is ArcadeDB faster than KuzuDB for graph analytics?
Yes. In LDBC Graphalytics benchmarks, ArcadeDB is 8.9x faster on PageRank (0.48s vs 4.30s), 6.6x faster on BFS (0.13s vs 0.86s), and 1.4x faster on WCC (0.30s vs 0.43s). Kuzu doesn’t even support LCC, SSSP, or CDLP algorithms. Results are fully reproducible.
Can I run my KuzuDB Cypher queries on ArcadeDB?
Yes. ArcadeDB’s OpenCypher engine passes 97.8% of the official Cypher TCK. Most Kuzu Cypher queries work as-is without rewriting.
What happened to KuzuDB?
KuzuDB was acquired by Apple in October 2025 and its GitHub repository was archived. The project is no longer maintained. Community forks like LadybugDB exist but lack corporate backing or guaranteed longevity.
Have questions about migrating from KuzuDB? Join our Discord — we’ll help you get up and running.