KuzuDB alternatives: a managed graph database without the embedded ceiling

KuzuDB (often just "Kuzu") is one of the most interesting graph databases to appear in the last few years. It is embedded: it runs inside your application process and stores data in a local file, the same way SQLite and DuckDB do. The project even describes itself as "DuckDB for graphs," and the comparison is earned: columnar storage, vectorized execution, and multi-core query parallelism, all tuned for analytical graph queries over large datasets. It speaks Cypher, supports vector indexes for GraphRAG, and is genuinely fast.

If you are reading this, you have probably already tried Kuzu, liked it, and run into the one thing it deliberately does not do: run as a server you can point multiple services at, or hand off to a managed host.

This post is about that gap. If your graph workload has outgrown a single embedded process, the practical alternative is a graph database that runs as a server, managed for you. In the Layerbase lineup that is TypeDB. It is not a drop-in replacement for Kuzu (more on that below, honestly), but if what you actually need is "a graph database I can run as a service," it is the right tool, and you can run it locally first.

Where the embedded model hits a ceiling

Embedded is a feature, not a flaw. For a single application that wants graph queries with zero network hops and zero operational overhead, Kuzu is excellent. The ceiling shows up when more than one thing needs the data:

• No network server. An embedded database lives in one process and one file. Two services cannot both open the same Kuzu database for concurrent writes. The moment you need a second consumer (an API, a worker, a dashboard) you have to build a serving layer in front of it yourself.
• No managed hosting. There is no "Kuzu Cloud" to click. You own the machine, the disk, the backups, the version upgrades, and the on-call pager.
• Concurrency and scaling. Embedded engines scale with the host process. Sharing a graph across services, or scaling reads independently, means wrapping Kuzu in infrastructure you now have to maintain.

None of this means Kuzu was the wrong choice. It means you have crossed from "library inside my app" to "shared database my systems depend on," and that is a different job.

Run a managed-style graph database locally with SpinDB

Before provisioning anything in the cloud, you can run TypeDB locally and see whether the model fits, using SpinDB. (What is SpinDB?) SpinDB downloads and runs database servers for you, no Docker and no manual binary management.

Install SpinDB globally:

npm i -g spindb    # npm
pnpm add -g spindb # pnpm

Create and start a TypeDB server:

spindb create graph1 -e typedb --start

SpinDB fetches the TypeDB binary for your platform, configures it, and starts the server. Check the connection endpoint:

spindb url graph1

localhost:1729

That is already the thing Kuzu does not give you out of the box: a graph database listening on a port that any number of clients can connect to. Leave it running while you explore.

TypeDB is not a Cypher drop-in (and that is fine)

Here is the honest part. Kuzu and TypeDB are both schema-first graph databases, but they do not share a query language or a data model:

• Kuzu is a property graph with Cypher. You define node tables and relationship tables, then match patterns with MATCH ... RETURN.
• TypeDB is a typed entity-relation database (a knowledge graph) with TypeQL. You define entity types, relation types, and attribute types, then match patterns with match ... get.

So this is a port, not a copy-paste. The good news is that the core idea, "describe a pattern of connected things and let the engine find it," carries over directly.

A small membership graph in Kuzu's Cypher:

-- Kuzu: schema, then a Cypher query
CREATE NODE TABLE Person(name STRING, PRIMARY KEY(name));
CREATE NODE TABLE Team(name STRING, PRIMARY KEY(name));
CREATE REL TABLE MemberOf(FROM Person TO Team);

MATCH (p:Person)-[:MemberOf]->(t:Team {name: 'Engineering'})
RETURN p.name;

The same model in TypeDB's TypeQL:

define
  name sub attribute, value string;
  person sub entity, owns name, plays membership:member;
  team sub entity, owns name, plays membership:group;
  membership sub relation, relates member, relates group;

match
  $p isa person, has name $name;
  $t isa team, has name "Engineering";
  (member: $p, group: $t) isa membership;
get $name;

Two things TypeDB gives you that a property graph handles less cleanly: relationships are first-class types that can own their own attributes (an assignment relation can carry a role-name), and the type system rejects invalid connections at write time (you cannot accidentally relate two teams as if one were a person). On top of that, TypeDB has inference rules: define logic once, and the engine derives new facts at query time that you never inserted. For a full walkthrough of schemas, multi-hop traversals, and inference, see Getting Started with TypeDB.

Provision managed TypeDB on Layerbase Cloud

Once the model fits locally, move it to a managed server without changing your code's shape. Layerbase Cloud provisions a managed TypeDB instance: pick TypeDB from the engine list and grab your connection details from the Quick Connect panel. You get TLS, backups, hibernation, and a connection string instead of a file path and a process you babysit.

The same SpinDB-style workflow applies in reverse for local management:

spindb stop graph1    # stop the local server
spindb start graph1   # start it again
spindb list           # see every instance you have

Most real systems are not graph-only. SpinDB manages 20+ engines, so you can run TypeDB next to PostgreSQL for transactional data or Valkey for caching, all from one CLI, then provision the same engines on Layerbase Cloud when you ship.

When to switch, and when to stay on Kuzu

Reach for managed TypeDB when:

• Multiple services share the graph. An API, a worker, and a dashboard all need to read and write the same data.
• You want a managed service. Backups, upgrades, and uptime are someone else's job.
• The type system and inference matter. Compliance, biomedical, and knowledge-base workloads where invalid relationships are a liability and derived facts are the point.

Stay on Kuzu when:

• You need embedded, in-process graph analytics in Cypher. If the whole appeal is "DuckDB for graphs" running inside one application with no network layer, Kuzu is still the right tool. Keep using it, or wrap it in your own service.
• It is a single-process analytical workload. One job, one file, fast columnar graph scans. That is exactly what Kuzu was built for.

The point is not that TypeDB beats Kuzu. It is that "embedded library" and "managed graph server" are different categories, and outgrowing the first does not mean you picked wrong. It means it is time for the second.

Wrapping up

Kuzu is a fast, modern, embedded graph database, and for in-process analytical graph queries it is hard to beat. The moment you need a graph database that runs as a shared, managed server, the embedded model is the constraint, not the engine.

TypeDB on Layerbase fills that role: a real graph database with a strong type system and inference, running as a managed service, with the same local-first workflow you already use. Spin one up locally with spindb create graph1 -e typedb --start, port a query or two from Cypher to TypeQL, and provision it on Layerbase Cloud when you are ready to share it.

Further reading: the TypeDB documentation and the Kuzu documentation for the embedded side of the story.