The graph database made for industrial digital twins.
TvennDB is a graph database for the AI era, where the digital twin carries the enterprise. One engine holds the structure, history and meaning of every asset, and scales out across a Kubernetes cluster as the fleet grows. Written in Rust by Hubbiot AB, proven under Hubbiot Nexus.
MATCH (s:Site {code: 'SUN'})-[:HAS_LINE]->(l)-[:HAS_MACHINE]->(m:Machine) WHERE m.status = 'down' RETURN l.name, m.serial, m.health ORDER BY m.health LIMIT 10 -- the same fleet, as it was on the day of the warranty claim {"query": "...", "as_of": 117247357747724288}
- Agents connect over MCPEach agent signs in with a credential of its own and sees only what its roles and membrane allow; the Enterprise edition also audits every call.
- Retrieval in one queryVector and text search feed straight into GQL, so an assistant gets the right documents with the asset they belong to.
- Answers it can explainHistory and time travel let an agent say what was true, when, and which commit changed it.
Four decisions, taken at the foundation.
Most graph databases were built for social networks and stretched towards industry. TvennDB starts from the asset: its structure, its history, a schema that holds and the documents that belong to it. The same record your AI agents read.
Sharded by what the asset contains
The ontology says which relations are containment: site, line, machine, component. Everything under one root lives on one shard, so a traversal inside an asset never crosses the network, and a fleet grows by adding shards. New roots land on the least loaded shard.
Every change kept, like git
Nothing is overwritten. Each commit carries a hybrid logical clock timestamp, the author, a message, tags and the time the change happened in the world. Any query runs as of any past moment; history, commit log and diff come with the database.
An ontology on every write
Labels declare typed properties with keys, enumerations, ranges, patterns and uniqueness; relations declare their endpoints, cardinality and containment. The ontology is versioned with author and message, dry run against the data before it takes effect, and retrievable as of any timestamp.
Graph, vectors and text in one query
Each shard keeps a vector index per vector property and a BM25 index per full text property. A nearest neighbour or text hit feeds straight into MATCH, so retrieval for an assistant is one GQL statement that respects the ontology and the caller’s permissions.
One database across many nodes.
TvennDB scales out, not up. In a Kubernetes cluster the graph is split over shard groups and the work over gateways, so storage, reads and writes grow by adding nodes, and a shard group keeps working when one of its members fails.
The graph spread over nodes
Each graph is partitioned by what its assets contain: a site, a line or a machine with everything under it is one partition, held by one shard group. Shard groups run as StatefulSets of their own across the cluster, and a new asset lands on the least loaded group. A traversal inside an asset stays on one shard; relationships between assets cross shards transparently.
The workload spread over nodes
A group of gateways stands in front of the shards. Every gateway answers queries and sends each one to the shard groups that hold the data, in parallel; scans, aggregates and vector searches run on every shard at once and are merged at the gateway. The leading gateway coordinates commits, and a transaction across shard groups commits with two phase commit under snapshot isolation.
Grow without downtimeEnterprise
Add shard groups with the Helm chart and rebalance: whole partitions move to the new groups online, with every version of their history, and latest reads see exactly one copy throughout. A move is resumable, and a single partition can also be moved by hand.
Survive the loss of a node
Every shard group is a Raft group, three members by default, spread over the nodes. The leader takes writes, a follower takes over when it fails, and members serve historical reads. PodDisruptionBudgets keep a quorum through node drains, and a consistency suite kills shard and gateway pods while it writes, checking that no acknowledged write is lost.
Where a twin database has to be different.
General purpose graph databases hope the hot path fits in memory. An industrial fleet does not: millions of parts, growing for decades.
TvennDB
TvennDB shards by the structure of the asset, so each asset lives on one shard. Writes across shards commit atomically and reads never see half a transaction.
A twin is trusted when it can say what was true on a given day. An audit table beside a database that overwrites gives a log, not an answer.
TvennDB
Every version stays readable. Query the fleet as it was, compare two dates, and see the commit behind each change.
AI helps only when it acts on a record that is current, complete and explainable. Most companies have that record scattered across systems.
TvennDB
TvennDB is that record: versioned, held to its schema, shared by people, systems and agents, and answering in milliseconds.
An asset crosses organisations. Each party needs its own slice, every AI agent its own credential, and the regulator a trail.
TvennDB
Roles per graph for every person, system and agent, and labels and subtrees hidden where they must be. The Enterprise edition adds every request, sign in and schema change in the audit log.
The gateway speaks the Model Context Protocol. An agent gets a principal of its own, sees only what its roles and membrane allow, and queries, reads the ontology and walks history through the same API as everyone else. In the Enterprise edition every call is also audited and metered.
Rules turn committed changes into events: a webhook with a signature and retries, a durable outbox any consumer can resume from, or a live stream. The ERP, the maintenance system and the dashboard learn about a change once, from the record.
The Explorer ships inside the gateway: a graph canvas, a query editor with time travel, and views for history, ontology versions, events and access, plus usage and the audit log in the Enterprise edition. No separate deployment, no build step.
Everything a production database needs.
One gateway in front of replicated shards, one ontology per graph, one history for all of it. The list below is what ships today; the items marked Enterprise come with the Enterprise edition.
- GQLYour team queries in the ISO standard, not a vendor dialect.The ISO graph query language: MATCH, OPTIONAL MATCH, WITH, UNWIND, UNION, INSERT, MERGE, SET, DELETE, aggregates, parameters, EXPLAIN and PROFILE.
- Ontology registryKeep data consistent as it grows and changes.Versions with author, message and activation time; owners and contributors; dry run and migration actions.
- Property indexesFast answers to the questions you ask most.Ordered, unique, composite and full text indexes kept in the same transaction as the data; ORDER BY and LIMIT pushed to the shards.
- Named graphsRun separate projects, customers or business units on one platform.Any number of isolated graphs per cluster, each with its own ontology, history, backups and placement.
- Time travelSee exactly what was true on any given day.Any query as of any timestamp; the ontology in force at that moment applies.
- Commit metadataKnow who changed what, when and why.Author, message, correlation id, event time and free tags on every commit.
- History and diffCompare any two points in time and see what changed.Every version of a node with its relationships, the commit log, and the change set between two points.
- Dated importsBring an existing system’s past with you, not only its present.Load an application’s past with its real dates, in order, and read it back as of then.
- ShardingGrow from one site to a global fleet without changing platform.Containment partitioning, placement on the least loaded shard, and a subtree moved under a parent on another shard with its history.
- ReplicationKeep serving when a server fails.Each shard is a Raft group; leaders take writes, members answer historical reads, snapshots catch up a member that fell behind.
- TransactionsEvery change lands completely or not at all, even across servers.Server side transactions with snapshot isolation; two phase commit across shards with recovery after a crash.
- Backup and restoreRecover a graph exactly as it was.Snapshots and log segments to a directory or any S3 compatible object store; restore a graph as it was.
- Principals and rolesGive every person, system and agent the right level of access.Users and services; read, write, schema and admin per graph; cluster administrators.
- Single sign onEnterpriseSign in with the identity provider you already run.OpenID Connect with PKCE, role claims mapped to graph roles, provider bearer tokens for machine clients.
- MembranesShare data across teams and partners without exposing what they should not see.Labels a principal cannot see and subtrees it is confined to.
- Rate and size limitsEnterpriseKeep one client from slowing down everyone else.Limits per API key and principal on request rate and result size.
- Audit and usageEnterpriseA full trail for auditors, and usage figures to allocate costs.Every request logged; usage by client, graph, label and hour.
- MCP endpointGive your AI agents a reliable source of truth to act on.Agents query the graph, read the ontology and walk history with their own credential, under the same roles and membranes as everyone else.
- EventsKeep ERP, maintenance and dashboards in sync automatically.Rules select committed changes by label, relation, property and value; webhooks with signatures and retries, a durable outbox and live streams.
- Import and exportMove data in and out without custom tooling.JSON Lines and CSV in and out, validated against the ontology, batched through the normal commit path.
- ClientsIntegrate from the languages and tools your teams already use.An HTTP API with an OpenAPI description, a Python client with no dependencies, and the tvenn command line tool.
- Kubernetes by defaultRuns on the infrastructure you already operate.A Helm chart with shard StatefulSets, gateway, Ingress, Prometheus metrics and a ServiceMonitor; runs on any conformant cluster.
- One binary to startTry it on a laptop in minutes.Development mode runs shards and gateway in one process and starts in under a second.
- The ExplorerExplore, query and administer without extra tools.A browser UI for the graph, queries, history, ontology, events and access, served by the gateway; usage and audit views come with Enterprise.
- Written in RustFast, predictable performance under load.One static binary per process, no JVM, no garbage collector pauses, predictable memory.
Measured against the field.
- 1TvennDB 1.0.0-rc.1latency 99 · throughput 9898
- 2Memgraph 3.13.2latency 65 · throughput 5160
- 3Neo4j 5.26.32 Communitylatency 48 · throughput 6052
- 4ArangoDB 3.12.12latency 34 · throughput 4738
- 5Dgraph 25.5.0latency 26 · throughput 3829
| Read latency | Throughput, 32 clients | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Point | 2-hop | Subtree | Aggregate | Fleet | Edges | Vector | Hybrid | Reads/s | 2-hop/s | Inserts/s | Updates/s | |
| TvennDB 1.0.0-rc.1 | 100 | 100 | 100 | 89 | 100 | 100 | 100 | 100 | 100 | 100 | 91 | 99 |
| Memgraph 3.13.2 | 79 | 47 | 64 | 100 | 92 | 32 | 67 | 66 | 46 | 34 | 74 | 58 |
| Neo4j 5.26.32 Community | 47 | 37 | 44 | 60 | 44 | 75 | 42 | 44 | 46 | 29 | 100 | 100 |
| ArangoDB 3.12.12 | 58 | 58 | 14 | 48 | 3 | 85 | 74 | 38 | 39 | 26 | 65 | 72 |
| Dgraph 25.5.0 | 28 | 36 | 12 | 28 | 37 | 22 | 25 | 27 | 32 | 34 | 41 | 45 |
| Read latency | |||||
|---|---|---|---|---|---|
| Point | 100 | 79 | 47 | 58 | 28 |
| 2-hop | 100 | 47 | 37 | 58 | 36 |
| Subtree | 100 | 64 | 44 | 14 | 12 |
| Aggregate | 89 | 100 | 60 | 48 | 28 |
| Fleet | 100 | 92 | 44 | 3 | 37 |
| Edges | 100 | 32 | 75 | 85 | 22 |
| Vector | 100 | 67 | 42 | 74 | 25 |
| Hybrid | 100 | 66 | 44 | 38 | 27 |
| Throughput, 32 clients | |||||
| Reads/s | 100 | 46 | 46 | 39 | 32 |
| 2-hop/s | 100 | 34 | 29 | 26 | 34 |
| Inserts/s | 91 | 74 | 100 | 65 | 41 |
| Updates/s | 99 | 58 | 100 | 72 | 45 |
Each test gives the best system 100 and the others their share of it: the fastest median latency divided by theirs, or their operations per second divided by the highest. The overall score is the geometric mean of the test scores, so a system cannot buy a high score with one outlier. A test a system cannot run is left out of its score and counted beside it.
The same synthetic plant (17,157 nodes, 18,012 relationships) in every database, each a single node with the same CPU and memory limits on one machine. Every answer is checked against the data before it is timed.
Dgraph 25.5.0 failed 936 of its property updates at 32 clients (transaction aborts beyond the retry budget); its rate counts the requests that succeeded.
| Query | TvennDB 1.0.0-rc.1 p50 / p95 ms | Neo4j 5.26.32 Community p50 / p95 ms | Memgraph 3.13.2 p50 / p95 ms | ArangoDB 3.12.12 p50 / p95 ms | Dgraph 25.5.0 p50 / p95 ms |
|---|---|---|---|---|---|
| Point lookup by key one robot by id | 0.31 / 0.41 | 0.66 / 1.28 | 0.39 / 0.65 | 0.53 / 0.65 | 1.10 / 1.21 |
| 2-hop expand robot → subsystems → components | 0.51 / 0.64 | 1.38 / 1.79 | 1.08 / 1.57 | 0.87 / 1.01 | 1.43 / 1.84 |
| Subtree count site → … → components, 5 hops inside one partition | 0.61 / 0.77 | 1.36 / 1.77 | 0.95 / 1.28 | 4.48 / 5.16 | 4.91 / 5.33 |
| Grouped aggregate worn components by part number, whole graph | 2.30 / 3.11 | 3.42 / 4.15 | 2.05 / 2.50 | 4.30 / 4.42 | 7.36 / 7.84 |
| Fleet-wide pattern 5-hop pattern over every site with a filter | 4.90 / 10.8 | 11.1 / 12.7 | 5.31 / 5.88 | 140 / 146 | 13.1 / 14.7 |
| Cross-partition edges count of FEEDS edges between cells | 0.57 / 0.75 | 0.77 / 1.19 | 1.82 / 2.29 | 0.68 / 0.81 | 2.62 / 2.92 |
| Vector top-5 nearest manual chunks to a fault description | 0.47 / 0.59 | 1.12 / 1.65 | 0.70 / 0.96 | 0.64 / 0.77 | 1.88 / 2.06 |
| Hybrid vector + graph top-3 chunks → manual → model → robots | 0.55 / 0.71 | 1.26 / 1.73 | 0.84 / 1.04 | 1.43 / 1.62 | 2.06 / 2.31 |
Method
Neo4j 5.26.32 Community, Memgraph 3.13.2, ArangoDB 3.12.12, Dgraph 25.5.0 measured 2026-10-17 15:26; TvennDB 1.0.0-rc.1 measured 2026-10-20 20:13, 1 node each, 4 CPUs, 6 GB, the same harness, data and container limits on the same machine each time. Latency is the median of 200 sequential requests per query after a warm up; within a run the systems take turns, so a noisy moment on the host lands on all of them alike. Systems with different dates were measured in separate runs, so taking turns evens out the host only within each run. Throughput is a 8 second window of independent clients spread over several client processes. Bulk load: TvennDB 1.0.0-rc.1 1.6 s, Neo4j 5.26.32 Community 3 s, Memgraph 3.13.2 0.9 s, ArangoDB 3.12.12 1.1 s, Dgraph 25.5.0 1 s.
Reproduce itThe harness, the adapters, the pinned container images and the raw results of every published run are available on request. A query a system cannot express is marked not supported rather than approximated.
Neo4j, Memgraph, ArangoDB and Dgraph are trademarks of their respective owners. They are named on this page only to identify the systems measured; no endorsement by them is implied.
Measured on a public workload.
| Query | TvennDB 1.0.0-rc.1TvennDB mean ms | Neo4j 5.26 CommunityNeo4j mean ms | TvennDB |
|---|---|---|---|
| IC1 Transitive friends with a given nameFriends with a name | 10.5 | 9.36 | 1.1× slower |
| IC2 Recent messages by your friendsFriends’ messages | 15.9 | 22.6 | 1.4× faster |
| IC3 Friends and friends of friends who have been to given countriesFriends abroad | 291 | 769 | 2.6× faster |
| IC4 New topicsNew topics | 9.32 | 8.22 | 1.1× slower |
| IC5 New groupsNew groups | 555 | 743 | 1.3× faster |
| IC6 Tag co-occurrenceTag co-occurrence | 6.68 | 605 | 91× faster |
| IC7 Recent likersRecent likers | 19.4 | 11.0 | 1.8× slower |
| IC8 Recent repliesRecent replies | 0.64 | 1.26 | 2.0× faster |
| IC9 Recent messages by friends or friends of friendsWider circle’s messages | 7.80 | 962 | 123× faster |
| IC10 Friend recommendationFriend recommendation | 113 | 127 | 1.1× faster |
| IC11 Job referralJob referral | 7.12 | 11.0 | 1.6× faster |
| IC12 Expert searchExpert search | 76.8 | 161 | 2.1× faster |
| IC13 Single shortest pathShortest path | 1.17 | 0.94 | 1.3× slower |
| IC14 Trusted connection pathsTrusted paths | 87.8 | 157 | 1.8× faster |
| IS1 Profile of a personProfile | 0.42 | 0.73 | 1.7× faster |
| IS2 Recent messages of a personRecent messages | 1.46 | 2.72 | 1.9× faster |
| IS3 Friends of a personFriends | 0.94 | 4.29 | 4.6× faster |
| IS4 Content of a messageMessage content | 0.30 | 0.73 | 2.5× faster |
| IS5 Creator of a messageMessage creator | 0.35 | 0.72 | 2.0× faster |
| IS6 Forum of a messageMessage forum | 0.44 | 0.73 | 1.6× faster |
| IS7 Replies of a messageMessage replies | 0.51 | 0.72 | 1.4× faster |
The Social Network Benchmark of the Graph Data Council (formerly the Linked Data Benchmark Council, LDBC) is the open workload graph databases are compared on. We ran its Interactive read queries at scale factor 1, 3,181,724 nodes and 17,256,038 relationships, on TvennDB and on Neo4j, each alone in a container with 4 CPUs, 6 GB on the same machine.
Method
Run 2026-10-20. Each system is configured for its budget the way its operators would: TvennDB 1.0.0-rc.1 with one shard, 2 GB store cache, 1.5 GB record cache; Neo4j 5.26 Community with 2 GB heap, 3 GB page cache. The 14 complex and 7 short reads use the workload’s substitution parameters, one client, 100 timed runs per query after 5 untimed ones. Every round times both systems after an untimed warm up pass, one system at a time and alternating, so the conditions on the host fall on both; a figure is the median of 3 rounds’ mean latency. Before timing, TvennDB’s answers were checked against Neo4j’s at scale factor 0.1: every query returns the same rows, for 15 sets of parameters per complex read and 20 per short read.
Queries and reproductionNeo4j runs the reference implementation’s Cypher queries (ldbc_snb_interactive_v1_impls, Apache 2.0); the TvennDB ports keep each query’s semantics in GQL. The loaders, the queries, the harness and the raw results of this run are available on request.
These are not LDBC Benchmark Results. We used the LDBC SNB Interactive workload (version 1) as a starting point: its data generator, dataset, parameters and read queries. The run is our own, has not been audited by the Graph Data Council, leaves out the update queries and does not use the official driver, so it is not comparable with audited LDBC Benchmark Results. LDBC Benchmark is a registered trademark; the workload is derived from the Graph Data Council’s specification under CC BY 4.0.
Run it yourself, or let us run it.
TvennDB Free holds the core and runs clustered production, free of charge. Enterprise adds what security, compliance and large operations need, under commercial terms; it is not yet available. SaaS is TvennDB operated for you by Hubbiot AB.
Free
Available nowThe core features, for teams that run their own infrastructure. Free of charge, no registration.
- Every feature on this page not marked Enterprise
- Clustered production: sharding, Raft replication, transactions across shards, backups
- Free of charge under the Elastic License 2.0, for commercial and production use too
- Signed container images for x86_64 and arm64 on ghcr.io/hubbiot, and a Helm chart, with every release
- Examples, compose files and Helm values on GitHub
Enterprise
Not yet availableFor enterprises that run TvennDB on their own infrastructure and need the enterprise features and commercial terms. Enterprise is not yet available; register your interest and we will tell you when it opens.
- Every feature in Free
- Single sign on
- Rate and size limits per key
- Audit log and usage reports
- Online rebalancing and partition moves
- Commercial licence terms and indemnification
- Long term support releases
- Runs where you decide: your Kubernetes, your data centre or your cloud
SaaS
SubscriptionFor fleets that cannot be down and teams that would rather not run a database. TvennDB with every feature, as a service operated by Hubbiot AB.
- Every feature in Free and Enterprise
- TvennDB operated by Hubbiot AB on our own European infrastructure
- Upgrades, backups and monitoring run for you
- Shards added as your graphs grow, no cluster of your own to run
Free and Enterprise compared
- GQL, the ontology registry, property indexes and named graphs
- Vector and full text search inside GQL
- History, time travel, diff and dated imports
- Sharding, Raft replication and transactions across shards
- Backup and restore to a directory or S3 compatible storage
- Users, services, API keys and roles per graph
- Membranes: labels a principal cannot see, subtrees it is confined to
- MCP endpoint, events and webhooks, import and export
- The Explorer, the Helm chart and Prometheus metrics
- Single sign onOpenID Connect with PKCE, role claims mapped to graph roles, provider bearer tokens for machine clients.
- Limits per keyRate and size limits for each API key and principal.
- Audit logEvery request, sign in and schema change logged, with its view in the Explorer.
- Usage reportsUsage by client, graph, label and hour, with its view in the Explorer.
- Online rebalancingMove partitions onto new shard groups, or off a group you remove, while the database keeps serving. Adding groups for new partitions is in Free.
- Commercial termsA commercial licence with indemnification, and long term support releases.
Any conformant Kubernetes with the Helm chart, a single machine for development, or as SaaS on Hubbiot AB’s own European infrastructure. Your data stays where you put it.
LicencesTvennDB Free comes as container images and a Helm chart under the Elastic License 2.0 from Hubbiot AB: free of charge, for commercial and production use too. Enterprise and SaaS will come under a commercial licence from Hubbiot AB. TvennDB is distributed as built software; the source code is not published. The TvennDB name and logo are trademarks of Hubbiot AB.
The database under Hubbiot Nexus.
Hubbiot Nexus keeps every asset, its composition, its documents and its whole history in TvennDB. The time machine is the database’s history, the assistant reads the twin through the MCP endpoint as a principal of its own, and every answer cites the records it came from.