Datalevin 1.1.0: State-of-the-Art Performance Across Data Models

When we released Datalevin 1.0.0, the message was that one database could handle application state across relational, graph, document, and logical workloads. With Datalevin 1.1.0, we can make a stronger case: that breadth comes with state-of-the-art performance on demanding benchmarks.

The results cover durable transactions, complex relational joins, social graph queries, nested documents, and recursive rules. Datalevin competes with SQLite, PostgreSQL, Neo4j, MongoDB, and dedicated logic engines, using the same database and Datalog query interface.

Here are the headline observations from the benchmark artifacts in the Datalevin repository:

Workload	Datalevin result	Comparison in the measured configuration
Durable transactions	114,739 records/s, synchronous strict WAL, batches of 1,000	3.57× SQLite's throughput
Relational queries	All 113 JOB queries in 38.073 seconds	3.37× as fast as PostgreSQL by total query time
Graph queries	Lower latency on 20 of 21 LDBC-derived read queries	8.56× as fast as Neo4j by summed time; 5.55× by geometric mean
Document reads	11,454 operations/s, one worker, workload C with document queries	3.99× MongoDB, the next fastest system
Logical queries	Lowest latency on all ten selected OpenRuleBench-derived tasks	1.07×–18.11× as fast as the fastest alternative for each task

Each comparison applies to the configuration and workload measured. Together, they make the case for Datalevin as a serious performance choice across data models. The details also show where other systems remain ahead.

Durable transactions

A useful database has to accept changes quickly while maintaining its indexes and honoring its commit promises.

The write benchmark inserts one million person records. Each contains a UUID string identity, first name, last name, and age. SQLite maintains its primary-key index and three explicit value indexes; Datalevin maintains its entity-attribute-value and attribute-value-entity indexes automatically. The comparison aligns logical records and API transaction boundaries, although the physical index work differs.

The chart uses Datalevin's strict WAL profile and SQLite's WAL with synchronous=FULL. Both use their ordinary OS sync behavior; the benchmark's separate macOS fullfsync condition is outside this chart. Data generation, transaction processing, and commit completion contribute to throughput.

For synchronous writes, SQLite is slightly faster at one record per transaction. Datalevin pulls ahead as batches grow: 1.51× at ten records, 1.96× at 100, and 3.57× at 1,000.

The asynchronous API adds another useful capability. It combines queued requests into physical transactions, reaching 245,485 records per second at a request batch size of 100 while retaining strict WAL acknowledgment. This is a different submission pattern from the blocking APIs: multiple requests remain outstanding, so request throughput should not be read as the number of physical commits or as single-request latency.

Concurrent callers also benefit. With four synchronous callers and 1,000-record batches, Datalevin reaches 151,622 records/s, compared with SQLite's 50,735, a 2.99× throughput advantage. In the mixed workload, each iteration looks up a person and upserts a complete record. The blocking strict-WAL paths deliver 5,616 pairs/s for Datalevin and 5,041 for SQLite. Datalevin's asynchronous path reaches 16,996 pairs/s, with reads using the latest available snapshot and no read-your-write barrier between outstanding requests. These results come from the retained concurrent and mixed artifacts.

The practical result is that Datalevin offers both a competitive blocking transaction path and substantial throughput when an application can batch or pipeline its work.

Relational queries: complex joins in 38 seconds

The Join Order Benchmark asks a harder question than point-lookup benchmarks do: can an optimizer choose good plans for complex joins over real, correlated data?

JOB contains 113 queries over an IMDB dataset comprising 21 tables. In Datalevin, the data becomes 277,878,411 datoms. Each engine executes a complete warmup pass followed by a complete measurement pass. PostgreSQL and Datalevin report planning and execution time inside the database, excluding client startup and communication overhead.

Datalevin completes the suite in 38.073 seconds, versus 128.231 seconds for PostgreSQL. SQLite spends 281.849 seconds on the 104 queries it finishes, and nine more queries hit the 60-second cutoff. Charging only that cutoff for each timeout gives SQLite a lower bound of 821.849 seconds, or 21.59× Datalevin's total. The hatched part of its bar makes those timeouts visible.

Datalevin's advantage comes from the suite as a whole: it is faster than PostgreSQL on 65 of 113 queries. PostgreSQL wins the other 48, including some queries where Datalevin's planning overhead is substantial. Datalevin spends 6.689 seconds planning, about 17.6% of its total. There is still room to make planning cheaper while preserving the execution savings.

For applications with complex relationships, the result challenges the idea that moving away from a relational storage model requires giving up relational query performance.

Graph queries: a general database takes on Neo4j

The graph harness implements all 14 Interactive Complex reads and seven Interactive Short reads from LDBC Social Network Benchmark Interactive v1. The SF1 dataset represents a social network; the Neo4j import contains approximately 3.65 million nodes and 20.63 million relationships.

Both engines run embedded, eliminating network transport from this comparison. Each gets a complete warmup pass, followed by a measurement pass in a fresh JVM. Filesystem pages can remain warm, while query parsing and planning are included in the measured call. Final-result caching is disabled.

In the September 1 comparison, Datalevin takes 4.480 seconds across all 21 reads, versus 38.346 seconds for Neo4j Community Embedded 2026.06.0. Datalevin wins 20 queries; Neo4j is about 5% faster on IC10.

The 8.56× summed-time advantage is influenced heavily by IC14. Giving each query equal weight through the geometric mean of its latency ratio still favors Datalevin by 5.55×. Across the seven short reads, the summed-time advantage is 2.95×.

Indexing policy matters here. Neo4j has ID uniqueness constraints and its automatic token lookup indexes, with no workload-specific secondary indexes. Datalevin automatically indexes attribute values. IC6 illustrates the difference: its selected parameter produces an empty result, and Datalevin can use an indexed tag-name lookup. Its 161.67× ratio describes that particular case; it should not be generalized to every graph traversal.

This is an LDBC-derived read-latency study, not an official audited LDBC throughput result. It retains one observation for one bundled parameter per query, and the first query can include lazy compiler initialization in the fresh JVM. All result counts agree; 17 queries also have identical canonical result digests across engines. Four have documented output-representation differences. Those details define what this strong result establishes.

Documents: indexed paths and fast application operations

Datalevin's indexed document type stores nested documents and indexes their paths. An application can query fields, numeric ranges, wildcard paths, and array contents while keeping documents intact.

The document benchmark compares this feature with PostgreSQL JSONB, SQLite JSON1, and MongoDB. It uses 10,000 documents and 10,000 measured operations per pass. The base mixes are reads and updates for A, reads for C, and read-modify-write for F. Each adds document queries with weight 30, producing roughly 23% document queries in the actual schedules.

All systems use explicit durable acknowledgment settings: Datalevin strict WAL, PostgreSQL synchronous_commit=on, SQLite WAL synchronous=FULL, and MongoDB {w: 1, j: true}. PostgreSQL, SQLite, and MongoDB receive indexes for the query mix where supported. Measurements include client-observed execution, transfer, and complete result-ID realization; Datalevin and SQLite are embedded, while PostgreSQL and MongoDB use local servers.

With one worker, Datalevin leads all three mixes. Its 11,454 operations/s on C is 3.99× MongoDB's 2,868, the best alternative. On A and F, its advantage over runner-up PostgreSQL is approximately 1.48× and 1.50×.

The four-worker results show a more varied picture. Datalevin reaches 32,192 operations/s on C, 2.43× PostgreSQL's throughput. PostgreSQL leads A by about 10.5% and F by about 5.3%. Datalevin's strongest advantage here is document querying; concurrent mutation remains an area for further improvement.

The latency breakdown shows where the query advantage comes from.

Datalevin has the lowest p50 for all five query shapes. Nested equality takes 0.057 ms; an any-depth wildcard takes 0.147 ms; array matching takes 0.207 ms. SQLite is competitive on indexed scalar paths, but the two nested-array shapes require scanning documents in this implementation.

Automatic path indexing makes a concrete difference for applications that store evolving, nested records and later need to ask precise questions about their contents.

Logical workloads: recursion and derived relations

Recursive rules are central to Datalog. They express reachability, dependency analysis, and relationships derived from other relationships in a compact form. Their execution can also generate enormous intermediate results.

The portable OpenRuleBench-derived suite tests transitive closure (TC), same generation (SG), and trees of joins (Join1). It compares Datalevin with SQLite, PostgreSQL, XSB, Soufflé, Clara Rules, and O'Doyle Rules under a query-and-full-result-materialization timing boundary. Data loading and program compilation are outside that interval.

The chart uses the September 1 Datalevin 1.1.0 rerun and the August 26 alternative-engine measurements. Input digests and completed answer counts match across those artifacts.

Datalevin has the lowest measured latency in all ten selected tasks. For cyclic transitive closure over 50,000 input facts, it materializes one million result rows in 102.59 ms. The fastest alternative, Soufflé, takes 1,030.36 ms, a 10.04× ratio. For Join1 b1 with both arguments free, Datalevin takes 99.14 ms, versus XSB's 1,795 ms, an 18.11× ratio.

Other leads are much smaller. Join1 b2 is 162.41 ms in Datalevin and 174.00 ms in XSB. The observed 1.07× ratio is useful to report alongside the large wins, especially with only one retained measurement per task.

The suite uses deterministic generated relations following the paper's task definitions; it does not recreate the lost historical input files. These ten tasks are a representative subset, excluding the designated Join1 a free/free stress case and the full scale/binding matrix. Clara's out-of-memory cell and O'Doyle's 60-second timeouts occurred during warmup. Unsupported cells remain marked N/A. Each Clojure wrapper uses an 8 GiB maximum heap; external engines have their own resource configuration.

This is particularly encouraging for a persistent database: expressive rules can deliver performance competitive with specialized logic systems.

What changed in 1.1.0

The release changelog describes improvements throughout the engine: better join-cost estimates, selective indexed lookups, parallel scans, execution in smaller work units, specialized transitive-closure evaluation, and faster batched writes and local identity upserts. Together, these changes target wasted intermediate work, allocation, and transaction overhead.

The release also makes strict durability the default when enabling WAL without an explicit profile. Python and JavaScript gain idiomatic, composable query and transaction APIs. Performance and usability move forward together.

These cross-system results measure the builds recorded in the artifacts. They are not a controlled 1.0-versus-1.1 experiment, so they do not assign a numerical speedup to an individual optimization.

The larger lesson is architectural. Relational joins, graph edges, document paths, and logical rules all benefit when the database can find relevant facts quickly and avoid producing unnecessary intermediate results. Datalevin's fact-based model gives those capabilities a common foundation.

Read the numbers, then try your workload

The measurements were collected on a 12-core Apple Silicon macOS host with Java 21.0.11; the JOB and logic studies identify the machine as an M3 Pro MacBook Pro with 36 GB of memory. They are project-run benchmarks with specific datasets, configurations, and timing boundaries.

The write study includes database growth in one measurement pass with no discarded warmup. JOB, graph, and document studies retain a measurement pass after a separate-process warmup; document runs also warm the newly built database within each pass. Logic uses a complete warmup and measurement in the same child JVM. These protocols produce observations, not confidence intervals, and their different metrics should not be combined into one overall score.

For reproducibility, the charts have a downloadable data snapshot with source-file hashes. The repository links above contain the harnesses and retained artifacts. The graph and logic charts use newer 1.1.0 artifacts than the older tables still present in their benchmark READMEs.

Datalevin 1.1.0 makes a strong case that one database can combine broad expressiveness with leading performance across demanding workloads. That opens up a useful design choice: keep application facts together, and use relations, graphs, documents, and logic wherever each is most natural.

Get Datalevin 1.1.0, explore the guide, and run the benchmark closest to your application. I would love to see what you build with it.