That changes with arcadedb-drivers, a new repository holding four published clients: an HTTP driver and a gRPC driver for Python, and an HTTP driver and a gRPC driver for TypeScript/JavaScript. All four are Apache-2.0, all four are generated from contracts ArcadeDB itself publishes, and all four are on the public registries today. They are also young: 0.1.0 releases under heavy development, with more languages on the way.

The four packages

All four talk to a running server, so they assume the client-server deployment rather than the embedded one. The Python packages need Python 3.10 or newer. The TypeScript packages need Node 20 or newer and are ESM only: import them, do not require() them. Version 0.1.0 of each targets ArcadeDB server 26.9.1, and every package README carries a compatibility table mapping driver versions to server versions.

HTTP or gRPC?

Two drivers per language is not indecision. HTTP and gRPC are the two transports ArcadeDB speaks, and each handles some workloads better than the other.

Start with HTTP. It works everywhere, it needs nothing beyond fetch or httpx, and for most application traffic the protocol is not the bottleneck. Move a workload to gRPC when you can point at the throughput number that justifies it.

One constraint is easy to lose an afternoon to, so here it is plainly. There is no browser build of the gRPC driver, and there will not be one until the server changes. ArcadeDB’s GrpcServerPlugin is plain grpc-java over HTTP/2, built on Netty, with no gRPC-Web handler, no Connect protocol, and no servlet adapter in front of it. A browser cannot speak raw HTTP/2 gRPC framing, so no client library in any language can reach this server from a browser tab. Browser code uses the HTTP driver. The limit is in the server.

Connecting and querying

The HTTP drivers are the place to start. Python, synchronously:

from arcadedb_driver import ArcadeDBServer, basic_auth

with ArcadeDBServer(base_url="http://localhost:2480", auth=basic_auth("root", "playwithdata")) as srv:
    db = srv.db("mydb")
    envelope = db.query(language="sql", command="SELECT FROM Person WHERE age > ?", params={"1": 21})
    print(envelope.result)

The async facade mirrors the sync one method for method:

import asyncio
from arcadedb_driver import AsyncArcadeDBServer, basic_auth

async def main() -> None:
    async with AsyncArcadeDBServer(base_url="http://localhost:2480", auth=basic_auth("root", "playwithdata")) as srv:
        db = srv.db("mydb")
        envelope = await db.query(language="sql", command="SELECT FROM Person WHERE age > ?", params={"1": 21})
        print(envelope.result)

asyncio.run(main())

Both are context managers because both own an httpx client with its own connection pool that has to be released. One detail that surprises people in production: omitting timeout disables timeouts entirely instead of falling back to httpx’s five-second default, because in httpx an explicit timeout=None means exactly that. Pass an httpx.Timeout if you want requests bounded.

TypeScript, same query:

import { createClient, basicAuth } from "@arcadedb/driver";

const server = createClient({
  baseUrl: "http://localhost:2480",
  auth: basicAuth("root", "playwithdata"),
});

const db = server.db("mydb");
const { result } = await db.query({
  language: "sql",
  command: "SELECT FROM Person WHERE age > ?",
  params: { 1: 21 },
});

A bearer token, such as a session token returned by /api/v1/login, works the same way in both languages: swap basic_auth for bearer_auth, or basicAuth for bearerAuth.

Because ArcadeDB is multi-model, language does real work here. "sql", "cypher", "gremlin": the same query call reaches all of them, and the driver does not care which one you picked.

The result envelope, and why truncated matters

Neither HTTP driver returns a bare array of rows. Both return the whole response envelope:

interface QueryEnvelope<T> {
  result: T[];
  limit: number;
  returned: number;
  truncated: boolean;
}

Of every API decision in the drivers, this is the one most likely to look like pointless ceremony, so here is the case for it. truncated is true when the server’s serializer hit its row cap while the query still had rows left to write. When that happens, result is a partial answer, not a short but complete one, and the two are indistinguishable by shape: a 5,000-row array that stopped early looks exactly like a 5,000-row array that ran out of matching records. A driver that unwrapped the envelope and returned only result would be handing you a value you cannot check.

So check it. When truncated is true, re-query with a narrower filter or a higher limit. Raising limit is not always the fix, though: a result whose true size exceeds the server’s hard ceiling (arcadedb.server.httpQueryMaxResultRows) is refused outright with a 413 rather than truncated, and past that point a narrower filter is the only way forward.

Transactions

Both HTTP drivers wrap ArcadeDB’s server-side transaction sessions in the idiom their language already has. Python uses a context manager:

with srv.db("mydb").transaction() as tx:
    tx.command(language="sql", command="INSERT INTO Account SET balance = 100")
    total = tx.query(language="sql", command="SELECT sum(balance) as total FROM Account").result[0]["total"]

TypeScript uses a callback:

const total = await db.transaction(async (tx) => {
  await tx.command({ language: "sql", command: "INSERT INTO Account SET balance = 100" });
  const { result } = await tx.query({ language: "sql", command: "SELECT sum(balance) as total FROM Account" });
  return result[0].total;
});

The rule in both is the same, and it is the one to get right: every call that should take part in the transaction goes through the tx handle, not the outer db object you opened it from. A call made through the outer handle while a transaction is open auto-commits on its own, outside the transaction, exactly as if no transaction were open.

The commit and rollback contract has three clauses in both languages. The block exits cleanly and the transaction commits. The block raises and the transaction rolls back, with the block’s own exception propagating: if the rollback also fails, that failure is attached as __cause__ (Python) or err.cause (TypeScript) rather than replacing the error you actually asked about. And if the commit itself fails, a best-effort rollback is issued first, so the server-side session is not left open until arcadedb.server.httpTxExpireTimeout reaps it, before the commit’s error is re-raised.

Streaming, over gRPC

The gRPC drivers exist for the workloads where HTTP’s request/response shape is the cost. A large result set over HTTP means paging through repeated calls; over gRPC it is one stream.

from arcadedb_driver_grpc import create_client, messages

with create_client("localhost:50051", insecure=True) as client:
    response = client.raw.ExecuteQuery(
        messages.ExecuteQueryRequest(database="mydb", query="SELECT FROM Person WHERE age > 21", language="sql")
    )

Note the target: gRPC’s native host:port form, not a URL. There is no scheme to parse and nothing to default, so you pass credentials=grpc.ssl_channel_credentials() for TLS or say insecure=True explicitly.

raw is the generated stub for the whole ArcadeDbService, so every RPC in the contract is reachable through it. On top, each client adds three wrappers for the RPCs the generated stub alone handles badly: stream_query, insert_stream, and transaction. Streaming a query in TypeScript:

for await (const row of grpc.streamQuery({
  database: "mydb",
  query: "SELECT FROM Person",
  language: "sql",
})) {
  console.log(row.rid, row.properties);
}

streamQuery flattens the server’s stream of row batches into one row at a time, and that is the only thing it does. It deliberately does not pick retrievalMode for you, because the three modes differ in ways only the caller can weigh:

• CURSOR, the default: runs the query once and streams results as you iterate. Pick it for a large result set you want to bound memory on.
• MATERIALIZE_ALL: loads the whole result set on the server first, then emits it in batches. Pick it when you need a stable snapshot and can afford to hold it server-side.
• PAGED: re-issues the query with LIMIT/SKIP per batch. Pick it when you want each batch’s consistency independent of the others.

Streaming inserts work the other way round. You hand insert_stream an async iterable of row batches, decide yourself how many rows go in a batch, and the driver owns the envelope bookkeeping that is easy to get wrong by hand: one stable session id for the whole stream, chunk_seq starting at 1 and incrementing, database set on the first chunk only, and last: true on the final one.

One security rule the gRPC drivers enforce in code instead of documenting and hoping. password_auth sends the password in plaintext gRPC metadata, so create_client refuses to pair it with a channel that has no transport credentials unless you pass insecure=True and say you meant it:

create_client("localhost:50051", auth=password_auth("root", "playwithdata"))
# raises InsecureChannelError

create_client("localhost:50051", auth=password_auth("root", "playwithdata"), credentials=grpc.ssl_channel_credentials())
# fine, the channel is encrypted

A bearer token is not a password and never trips this guard.

One contract, many clients

In a year, the four packages will matter less than where their code comes from.

contracts/ in the repository holds two files: the OpenAPI specification every HTTP client is generated from, and the Protobuf .proto every gRPC client is generated from. Both are fetched from ArcadeDB itself; neither is maintained by hand alongside it. No client package edits its generated types. Each client’s build regenerates from the contract and fails on a drift gate: if the checked-in generated code and a fresh regeneration disagree, the build breaks rather than shipping a client that quietly describes a server that no longer exists.

This is the failure mode the design is aimed at. Hand-written drivers rot silently. The server adds a field or tightens a response, and the driver keeps compiling and keeps returning plausible values until someone loses a day to it. A generated client with a drift gate cannot get there: the disagreement becomes a red build the day the contract moves, and adding a language later means writing a generator config, not re-reading the server’s source and hand-writing types.

Two smaller things follow from the same idea. Every release is built and published by CI from a clean checkout, never from anyone’s laptop: the npm packages carry provenance attestations, and the PyPI packages go out through trusted publishing with no long-lived token anywhere in the chain. And nothing publishes automatically. Every release is a human-triggered workflow dispatch.

What is next

These drivers are under heavy development. They are 0.1.0 releases, and while the APIs above are the ones we intend to keep, some of them will change before 1.0. Pin a version if you need the surface to hold still, and read the changelog before you move off it.

More languages are planned. The repository is already laid out for them: go/ and other language directories will appear as siblings of typescript/ and python/, each generated from the same two contracts. None exist yet, but the contract-first design is what makes adding one tractable.

Run them against a real workload and tell us where they get in the way. Issues and pull requests go to ArcadeData/arcadedb-drivers.

• Repository: github.com/ArcadeData/arcadedb-drivers
• Documentation: Native drivers
• Packages: arcadedb-driver and arcadedb-driver-grpc on PyPI, @arcadedb/driver and @arcadedb/driver-grpc on npm

At a Glance

Upgrading is strongly recommended for every deployment. There are breaking changes and behaviour changes; no schema migration is required, and no existing database is rewritten.

Major Highlights

Backups Are 27.6x Faster and No Longer Stall the Database

A full backup ran single-threaded deflate at level 9, CPU-bound at 20-40 MB/s, and it suspended page flushing for the whole window: dirty pages piled up until arcadedb.flushSuspendMaxDeferredRAM was reached, committers were throttled, and LSM compaction was postponed. HA snapshot shipping and cluster verify did the same thing (#6072, #6075, #6086).

Measured on a 1.25 GB database:

• Parallel compression, tunable with arcadedb.backup.compressionLevel (new default 1, was 9), arcadedb.backup.compressionThreads and arcadedb.backup.maxMBPerSecond. The ZIP format is unchanged and archives written by older versions restore normally.
• Parallel restore, largest entry first, behind a 256 KB buffered read instead of ZipInputStream’s unbuffered 512-byte reads (arcadedb.restore.threads). Even the sequential path went from 5.16 s to 3.96 s.
• A page-level copy-on-write snapshot replaces flush suspension: arcadedb.pageSnapshotEnabled, arcadedb.pageSnapshotMaxRAM, arcadedb.pageSnapshotMaxSize, arcadedb.pageSnapshotSpillPath. Backups, HA snapshot shipping and the /checksums endpoint take a point-in-time view without ever stopping the flusher.
• Two JVM-wide stalls are gone with it. The deferred-flush backpressure gate was process-wide, so one database’s backlog stopped the flush thread for every database on the server (#6200), and publishPages blocked inside the global page-manager lock whenever the flush queue filled, serialising the commits of every database behind one database’s write burst (#6259). Both are per-database now.

The trade is 7.5% archive size for 27.6x backup time. Set arcadedb.backup.compressionLevel=9 if the archive size matters more to you than the backup window.

Records Larger Than a Page: Lost Updates, Phantom Rows and a 16% Space Leak

A record that outgrows its page is stored as a chunk chain or behind a placeholder pointer. Re-triaging #5279 turned up a whole family of defects on that path, every one of them silent:

• A lost update. Two transactions updating the same placeholder-backed record (pointer on one page, content on another) both committed and one write vanished, with no ConcurrentModificationException (#6141). The content page is version-checked now, so the conflict is raised.
• A record returned twice. A SELECT returned a placeholder-backed record under two different RIDs when its content had spilled into chunks, so count(@rid) reported 2 for one record (#6196).
• A 16% space leak. CRUDTest.multiUpdatesOverlap ended with 243,821 orphaned chunk slots out of 1,545,495, because a shrink ending exactly on a chunk boundary never freed the tail and nothing ever reclaimed them, although three code comments promised otherwise (#6319, #6294). CHECK DATABASE FIX now sweeps them and reports orphanedChunks / orphanedChunksReclaimed.
• False conflicts. Reading a multi-page record failed with “was modified during read after N retries” when an unrelated record’s chunk on a shared page was written (#6217), and eight threads rewriting different large records on one page got ConcurrentModificationException, five of eight exhausting TX_RETRIES (#6129). Chunked head slots take part in the disjoint-slot merge now, and a read validates only its own chain.
• A permanent size ratchet. A chunked record’s head chunk shrank to the smallest size it ever had and never recovered, so a record oscillating in size degraded for ever into a longer chain with unusable gaps (#6163). A record that shrinks back inside its slot is collapsed to a plain record again (#6178, #6286).
• A checker that reported a clean database. After CHECK DATABASE FIX force-deleted a record with a broken chain, the placeholder pointing at it was left dangling, so count(*) said 8 and a scan said 7, permanently, while the report said totalErrors: 0 (#6292).

Free-space accounting was fixed with them (#6154, #6339), and a self-referencing edge-list chunk no longer hangs an ordinary traversal in a request thread (#6278).

Wrong Results in Ordinary SQL

Five independent defects, all of them returning a plausible answer to the wrong question:

• NOT IN returned the IN result set. WHERE prop NOT IN [...] on an indexed property returned 1 row where 25,089 matched, because the index planner served the lookup without consulting the NOT flag. Present since 26.7.1 (#6796).
• SELECT DISTINCT ... ORDER BY ... LIMIT n returned fewer than n rows, because the Top-K bound was applied before deduplication (#6923).
• A multi-key GROUP BY grouped on the last key only: the synthetic alias counter was final int i = 0 outside the loop, so every key got the same alias (#6924). DISTINCT was silently dropped whenever the statement also had GROUP BY, UNWIND or expand() (#6925).
• An index range scan ignored its own transaction’s deletes. A range query inside a transaction returned rows deleted or re-keyed in that same transaction, including rows that did not match the WHERE clause (#6927).
• An indexed range over non-ASCII text returned nothing. BinaryComparator ordered STRINGs by UTF-16 code units while LSM index pages order them by unsigned UTF-8 bytes, so a scan whose bounds fell where the two orders disagree returned zero rows although both keys were in range (#6997).

Also: the ?? null-coalescing operator always returned its right operand because the AST builder had no visitor for it (#6393); WHERE @rid > :param returned nothing while the same RID as a literal worked, breaking RID-cursor paging (#6188); @rid IN (SELECT ...) never matched (#7054); TRUNCATE TYPE inside an explicit transaction committed the caller’s transaction from the inside, so BEGIN; TRUNCATE TYPE; ROLLBACK destroyed 1,000 records (#6220); and EXPLAIN UPDATE ... submitted as sqlscript executed the update, which ran unbounded for hours in production (#6648).

Indexes Are Used Where They Were Not

Two more index defects worth naming: INSERT followed by CREATE INDEX in the same transaction produced an index that was readable, reported healthy by CHECK DATABASE, and missing the record (#6324); and a composite index mixing a scalar property with one BY ITEM/BY KEY/BY VALUE property was never updated when only the scalar changed (#6934).

Vector Search: Opening a Database, Rebuilding the Graph, and Recall

Most of this was measured and reported by @tae898 on real corpora.

• Opening a database is constant-time again. Every open parsed every page of every LSM_VECTOR index to rebuild the in-memory location map, about 1.4 s at 10M vectors, even for a session that never searched. The map is materialised on first use now (#6722). A Graph Analytical View was rebuilt by a full graph scan on every open too, 4.03 s at 1M vertices for an open-and-close with no query; the CSR is persisted at clean close with a freshness certificate and restored lazily (#6583, #6632).
• Rebuilds stopped ambushing the first query. A session that inserted before its first search paid a full synchronous rebuild on the search thread: 2,618 ms versus 215 ms on 20,000 vectors, 128,543 ms at 1M (#6772). A persisted graph is reused as a prefix and only the gap is built (#6655, #6798). A single insert into a settled 50,000-vector index no longer triggers an 8-14 s rebuild 15 s later (#6496), and the rebuild threshold scales past 250,000 vectors where the linear delta scan was ~79% of query time (#6797).
• Recall stopped falling off a cliff. The adaptive efSearch beam narrowed from 100 to 20 once an index passed 10,000 nodes: recall@10 fell from 0.9200 at 9,000 vectors to 0.5420 at 11,000, for under 1 ms saved. The beam widens with graph size now, and an explicit efSearch: 100 is honored (#6494).
• A selective filter makes search faster, not slower. A RID allow-list made search slower the narrower it was (p50 2.020 ms unfiltered, 30.145 ms for 5 RIDs, against 0.090 ms for a direct pre-filter). A pre-filter plan scores the allowed vectors directly when the allow-list covers at most VECTOR_INDEX_PREFILTER_MAX_SELECTIVITY (default 20%) of the index (#6502, #6514).
• Builds use the machine. Graph construction is 93.4% of a DEEP-10M build and ran on availableProcessors()/2 threads with 31.04% of CPU burned in LongAdder.add on the distance path; striped counters cut 2-5x per lookup and the pool defaults to cores minus one, settable with arcadedb.vectorIndex.graphBuildParallelism (#5577). The location index went from ~90 to ~32 bytes per live vector (#5588).
• Two silent wrong answers. A partial compaction of the sparse-vector index could permanently resurrect deleted documents or revert updates, because a merged segment got a globally new highest id and outranked a newer tombstone under “newest wins” (#6379); pre-fix merged segments are reported at index open. And a grouped search returned the groups with the lowest RIDs rather than the best-scoring ones (#5761, #6936).

openCypher: a Correctness Sweep, Then Neo4j Compatibility

A large batch of wrong-result defects came from differential fuzzing against Neo4j and Memgraph by @YGY-001 and @shulei5831sl, plus follow-ups. The shape is always the same: the identical query written two ways gives two answers.

• An edge variable read only inside a list predicate was anonymised, because the reference check scanned whitespace-stripped text instead of the AST, so the WHERE read a missing binding and dropped every row (#6567, #6599); the same check had no CREATE/MERGE case, so CREATE (c {since: r.since}) wrote null (#6573).
• Relationship uniqueness was scoped to one pattern part instead of the whole MATCH clause, so the same OPTIONAL MATCH returned different row counts depending on whether the rows went through collect/UNWIND first (#6310).
• A label disjunction (y:A|B) on a node bound by expansion matched nothing because the target-side check ANDed the alternatives (#6338), a backticked label in a WHERE never matched (#6345), and labels() dropped a vertex’s own type under inheritance (#6363).
• MERGE created duplicates when the anchor vertex was bound earlier in the same query, breaking idempotency on the most common graph-building shape (#6461).
• A standalone leading OPTIONAL MATCH with more than 100 matches never terminated, re-running its scan from scratch on every pull batch and emitting the first 100 rows for ever (#6668).
• MATCH p=(a)-[*1..N]->(b) materialized every path and exhausted a 512 MB heap on a modest fan-out graph where SQL TRAVERSE answered in under a second; variable-length traversal is a lazy DFS generator now (#6097), and the cost-based optimizer plans it instead of falling back to the legacy executor (#5358).

On the compatibility side: 12 APOC-compatible functions and procedures including apoc.refactor.mergeNodes, apoc.refactor.cloneNodesWithRelationships and apoc.do.when (#6059, #6060, #6157); db.index.fulltext.queryNodes / queryRelationships bring BM25 full-text search into Cypher (#6729); and the Neo4j 5 dynamic-label syntax SET n:$(expr) / REMOVE n:$(expr) is implemented, where it used to parse and then create a vertex type literally named $(node.labels) (#7059, #7093).

GQL: Quantified Path Patterns, Phase B

Quantified Path Patterns beyond the single-relationship case (ISO/IEC 39075 §15.4) were rejected with FeatureNotImplemented. A parenthesised sub-pattern can now repeat with a quantifier, carry its own WHERE evaluated per repetition, bind group variables as LIST<NODE> / LIST<RELATIONSHIP>, and support grouped path assignment with relationship isomorphism enforced across the group (#4531).

Three pre-existing bugs were fixed on the way: the Phase A rewrite dropped an inner endpoint label and could return rows through wrongly-labelled nodes, an inner node’s inline WHERE could not see earlier bindings of the same repetition, and deep repetitions overflowed the stack at about 5,000 (they run iteratively to 20,000 now).

The Postgres Wire Protocol Works With the Defaults Your Driver Uses

Twenty-eight defects, most of them reported by driver behaviour rather than by reading the spec:

• UPDATE on a vertex type in autocommit, the JDBC, psycopg and Spark default, failed with Transaction not active while document and edge updates succeeded. A vertex can be modified outside a transaction now, and UPDATE/DELETE/INSERT in autocommit each run as one statement-level transaction (#7096, open as discussion #1588 since 2024).
• An error inside BEGIN wedged the session permanently: ReadyForQuery never reported 'E', COMMIT/ROLLBACK were not recognised, and every further statement was silently swallowed (#6457, #6543).
• JDBC fetch size silently truncated results to the first N rows: PortalSuspended was written before the rows and the portal removed, so the follow-up Execute found nothing (#6458).
• pgjdbc’s sixth execution of a PreparedStatement served stale rows: re-Binding an already-executed named statement reused the portal without resetting executed (#6660).
• Schema probes answered nothing. WHERE 1=0 and LIMIT 0 over a computed projection returned no RowDescription at all, which is what Spark, Tableau and several JDBC and BI tools send first (#6156, #6185).
• An idle connection busy-polled its socket ten times a second because readMessage() never blocked, so N pooled connections cost 10N wakeups per second (#6410).

MongoDB, Bolt, gRPC, GraphQL, Redis and Gremlin got the same treatment; see Wire Protocols below.

Optional mTLS on the Raft Transport

The gRPC transport between cluster nodes (AppendEntries, RequestVote, snapshot transfer) ran in plaintext with no peer authentication, so any host that could reach the port could inject log entries. Optional mTLS is configurable through arcadedb.ha.tls.enabled, arcadedb.ha.tls.certChainFile, arcadedb.ha.tls.privateKeyFile, arcadedb.ha.tls.trustCertCollectionFile and arcadedb.ha.tls.mutualAuth (#3890).

Off by default. Startup fails fast if any PEM file is unreadable, mutualAuth=false gives server-only encryption, and the leader’s own Raft client plus the Kubernetes auto-join probe were fixed to carry the same TLS parameters instead of dialling in plaintext.

Certificates are read from disk at startup only, so rotating them requires a restart.

Security Advisories

This release closes six security advisories, each published in full (impact, affected versions and credit) as a GitHub Security Advisory on the repository. All six affect 26.8.1 and earlier and are patched in 26.9.1.

Per-type ACL enforcement

• GHSA-wjhv-79gv-2pqg (high): TimeSeries types ACL entries were not enforced on the write paths. Reported by @FEARIS2.
• GHSA-2c8m-q484-jv7m (high): index-target and TimeSeries reads, writes and counts reached records without the bucket-level permission check. Reported by @ruispereira.
• GHSA-27vw-j8qc-5h7x (medium): batch parallel-flush edge-connect writes ran on async workers with no principal bound, bypassing per-type ACLs. An incomplete fix of GHSA-c23x. Reported by @manus-use.
• GHSA-chrr-vr3p-crcc (medium): the AI Chat query_database tool bypassed per-type and per-bucket ACL enforcement. Reported by @T4ran24.

Untrusted input reaching the host

• GHSA-67m7-7w7g-mpmh (high): the IMPORT DATABASE SSRF guard did not extract IPv6 transition addresses (NAT64, 6to4, Teredo), so an internal IPv4 address could be reached through an IPv6 spelling. An incomplete fix of GHSA-4w2m. Reported by @tonghuaroot.
• GHSA-j57p-qmrh-v7xv (high): the script-trigger sandbox’s DENIED entry for java.util.ResourceBundle was bypassed by its subclasses, allowing classpath credential disclosure. Reported by @baeseungwon1010.

Three further advisories were published just after the 26.8.1 release and are fixed in 26.8.1, not here: GHSA-rv64-62hr-wv2p (CVE-2026-76223), GHSA-wcm5-4wjm-9wj3 and GHSA-mmww-w3w3-6r86.

Also Hardened in This Release

Pre-authentication denial of service on the wire protocols. An unauthenticated client could exhaust the server with a handful of bytes on three protocols, all found by @ruispereira:

• The Bolt WebSocket transport sized a byte array from the client’s 64-bit frame length with no bound, so a ~14-byte frame declaring a 2 GB payload forced a 2 GB allocation before the handshake (#5894); the PackStream decoder did the same from a 32-bit length and recursed without a depth limit (#5918); and LIST_8/LIST_16/MAP_16 element counts bypassed those guards while ListFrame allocated eagerly, so a ~3 KB message could force ~256 MB of live heap (#6800). New bounds: arcadedb.bolt.websocket.maxFrameSize (16 MB), arcadedb.bolt.maxMessageSize (16 MB), arcadedb.bolt.packstream.maxValueLength, maxElements, maxDepth.
• The Redis wrapper parsed RESP arrays with unbounded recursion and an unvalidated element count, so a ~47 KB message of nested arrays overflowed the stack with no credentials (#5895). New bounds: arcadedb.redis.maxMultiBulkDepth (32), maxMultiBulkLength, maxBulkLength.
• The Postgres handshake had no pre-authentication read timeout and accepted unbounded startup parameters, so a client that connected and sent nothing pinned a thread and a file descriptor for ever (#6377); the listener also accepted unbounded pre-auth connections (#6412). Redis and Bolt got the same window, and TCP keepalive is enabled on server sockets so a half-open connection is dropped by the OS rather than pinning a thread for ever (#6761).

Catastrophic regex backtracking. SQL MATCHES and openCypher =~ handed a user pattern straight to java.util.regex with no bound, so (.*a){20}$ on a 41-character string pinned a query thread indefinitely and arcadedb.command.timeout could not stop it. The new arcadedb.command.regexTimeout (default 1000 ms) bounds every regex evaluation independently of the command timeout (#5886). Parser recursion is bounded too, in Cypher, SQL and GraphQL (#5851, #5853).

Other hardening

• restore database <url> followed redirects with no per-hop revalidation, so the one-shot host check was bypassed by a 3xx redirect or DNS rebinding to an internal address (#6381). The two independent SSRF checks on import database also read two different configuration keys, so the documented opt-out worked for only one of them (#6474).
• Revoked database-level grants stayed in effect until restart. A group’s updateSchema, updateSecurity and updateDatabaseSettings grants and its resultSetLimit/readTimeout were frozen at the values seen when the user first touched the database (#6806).
• The polyglot (JS) engine kept script parameters bound in the shared context after each command, so a later js command from any caller could read a previous caller’s parameters and globals (#6759), and the host-class allow-list’s ancestor walk skipped package-wildcard DENIED entries (#6045).
• Credentials stopped being written down. The console wrote every connect remote: ... <password> and create user ... identified by <password> line to ./.history in cleartext and echoed it in -b mode (#6829), and with arcadedb.bolt.debug=true the HELLO message logged the caller’s cleartext password (#6801).
• POST /api/v1/login minted a session per call into an unbounded map, storing untruncated client-controlled headers for at least 30 minutes (#6809), and the db tag of the arcadedb.http.requests meter was the raw path parameter with no existence check, so unauthenticated requests grew the meter registry without bound (#6805).
• Bolt LOGOFF was accepted in any state and left the open result stream and explicit transaction alive on a now-unauthenticated connection, so a later user could commit writes made before the user change (#6803).
• The Gremlin shaded jar bundled Jackson 2.15.2. TinkerPop’s gremlin-shaded ships its own relocated copy with the original version metadata, so Docker Scout and grype flagged it and GraphSON serialisation actually ran on it. The jar is rebuilt on the project-wide Jackson 2.22.2 (#7097).
• WAL recovery allocated a page array straight from a file-read count, so a corrupt page-count field produced an OutOfMemoryError the recovery guard could not catch (#6932), and PromQL query_range overflowed its step-count guard and wedged an Undertow worker in an unbounded loop (#6807).

New Features

SQL

• INSERT ... ON DUPLICATE KEY SKIP: a multi-record insert no longer aborts the whole batch on the first duplicate key. Records violating a unique index are skipped and reported with @skipped: true, the offending index and the key; works with CONTENT, SET and INSERT ... FROM <query> (#4918).
• CHECK DATABASE FIX RECLAIM UNREFERENCED FILES deletes files with no schema component, left behind by an abandoned HA schema instalment sequence, and reports them (#6189).
• CHECK DATABASE ... DEEP is a new tier for the expensive TimeSeries sealed-store checks, with a FIX arm that repairs what is derived from the sealed blocks (#6360).
• SQLFunction#isDeterministic() lets a function opt into plan caching and constant folding; abs, pow, sqrt, coalesce, ifnull, ifempty, if, decode and strcmpci do (#6190).

Query Languages

• GQL Quantified Path Patterns Phase B, see the highlight above (#4531).
• 12 APOC-compatible Cypher functions and procedures: coll.sum, coll.avg, coll.union, coll.unionAll, coll.toSet, coll.pairsMin, math.round, convert.toString, number.format, apoc.do.when, apoc.refactor.mergeNodes and apoc.refactor.cloneNodesWithRelationships.
• db.index.fulltext.queryNodes / db.index.fulltext.queryRelationships YIELD (node|relationship, score) from ArcadeDB’s BM25 FULL_TEXT index inside a Cypher statement, matching Neo4j (#6729).
• Cypher dynamic labels SET n:$(expr) and REMOVE n:$(expr), plus REMOVE n IS Label.
• The GQL standalone FILTER clause actually filters (#6574).

Server and Operations

• Optional mTLS on the Raft gRPC transport, see the highlight above (#3890).
• A per-protocol HA routing table. getRoutingTable(ROUTING_PROTOCOL) and a grpc: field in arcadedb.ha.serverList, so a follower refusing graphBatchLoad can name a dialable gRPC address in the arcadedb-leader-grpc-address trailer instead of only the leader’s HTTP address (#6091).
• /api/v1/cluster reports live Raft membership. Every peer carries inConfiguration, a declared peer the cluster no longer contains reports role NOT_IN_CONFIGURATION, the divergence raises peers-not-in-configuration / peers-not-in-server-list alerts, and Studio shows the state (#7040).
• A skip mode for the bulk importer. -onRowError skip|abort (default abort) logs and skips a malformed or out-of-range row instead of aborting the whole job, counting it in the summary (#5968).
• Exponential backoff with full jitter for transaction retries, starting from the new arcadedb.txRetryDelayBase and doubling per attempt up to the arcadedb.txRetryDelay cap, instead of drawing from the same flat window on every attempt (#5587).
• The OpenAPI spec is a publishable, self-identifying contract, smoke-tested against a TypeScript client generated from the server built in the same commit (#4894).

Major Fixes and Improvements

Storage and Integrity

• CHECK DATABASE at scale. A hub vertex’s adjacency list was re-walked once per edge, O(degree²) on super-nodes: one CHECK DATABASE FIX on a real 657 GB graph measured 80h19m. A per-pass probe cache takes that to O(degree) (#6062). Orphan edge records are named and reclaimed (#6090), and repairs are budgeted and committed in batches instead of stopping (#6320).
• A fenced database no longer hangs with “No flush progress for 60000 ms”, reported twice from production during a GraphBatch import and a DELETE ... BATCH loop. A database fenced after a failed post-WAL commit stranded queued page-flush acks (#6505).
• Renaming a vertex type broke every subsequent edge insert on that type with SchemaException: Bucket with name 'Human_0_out_edges' was not found, on both 26.7.2 and 26.8.1, because the edge-chunk bucket and file names were derived wrongly and mangled further on every rename (#6667).
• A forward bucket scan fetched one page past the end, synthesising a phantom zero-filled page and inserting it into the global read cache, and a record that failed to materialise during a scan was logged and silently dropped from the result set (#6014, #6015).
• removeSuperType() withdrew only the type’s own buckets from the ancestor’s polymorphic cache while linkSuperType() had contributed the whole subtree, so after unlinking B from A a grandchild’s records still came back from SELECT FROM A (#6935).
• A date pattern with MMM/EEE rendered month names in the JVM default locale, so a schema date written on an it_IT node failed to parse on another, and FileUtils.copyFile ignored transferTo’s return value so a file over 2 GB was silently truncated (#7112).

Indexes

• CREATE INDEX <name> IF NOT EXISTS answered created: true under the requested name while silently reusing a pre-existing index on the same property, so SEARCH_INDEX('<name>', :q) later failed or ranked nothing (#6921).
• Index configuration is no longer lost on the repair and restore paths. TRUNCATE TYPE, CHECK DATABASE FIX, adding a bucket and adding a supertype recreated FULL_TEXT, geospatial and LSM_SPARSE_VECTOR indexes from the underlying LSM-Tree’s metadata, so analyzers, BM25 parameters, geohash resolution and sparse-vector settings silently reverted to defaults (#5742, #5934).
• REBUILD INDEX no longer returns silently when it fails. Both it and CHECK DATABASE FIX retried the whole drop-and-create body, so a failure after the drop had committed could leave the index permanently missing (#6040).
• CONTAINSTEXT on a single-property full-text index split its literal on :, so any value containing a colon returned no matches (#6382); two CONTAINSTEXT conditions on the same property sent only the first to the index (#6427); and a field-qualified phrase query ignored its field (#7000).
• An LSM_TREE index stores a LINK key as a compressed RID of about 2-7 bytes instead of a fixed 12 per column, roughly halving the key bytes of an (@out, @in) edge de-duplication index (#5703).
• An index cursor allocates 6-8 fewer short-lived objects per row on a unique-index range scan, about 7M objects saved on a 1M-row scan (#6944).

Numeric Correctness

A family of unchecked narrowings, all found by @ruispereira, all silent:

• Storing an out-of-range value in an INTEGER/SHORT/BYTE property wrapped it: SET n = 3000000000 stored -1294967296 with no error (#5905).
• SUM()/AVG() over an INTEGER column overflowed silently once the running sum passed Integer.MAX_VALUE: five rows of 2,000,000,000 gave sum = 5705032704 instead of 10,000,000,000 (#5906).
• LIMIT 2147483648 narrowed to Integer.MIN_VALUE and returned 0 rows, a finite double above Float.MAX_VALUE was dropped from map JSON, and a DOUBLE MIN/MAX constraint was checked as float (#5919).
• BinaryComparator narrowed the wider operand to the first operand’s width, giving a non-antisymmetric order, and parsed string operands with Integer.parseInt, so WHERE n < 'abc' crashed (#5900).
• NaN narrowed to 0 when converting a Double/Float to an integral type, scalar and array paths alike (#5970, #6020).

SQL

• split() returns a String[], and the operator surface now handles it. CONTAINS on either side, CONTAINSANY, and join()/sort()/first()/last()/asList() all mishandled a plain array: 'a b c'.split(' ') CONTAINS 'a' was false, join() leaked [Ljava.lang.String;@7a8fa663, sort() returned the input unsorted (#6984, #7084).
• sum/avg/min/max over zero matching rows returned an empty result set while count(*) returned one row with 0; they return one null row now, per ANSI SQL (#6680).
• astar() computed every heuristic cost as if the node were the start, so A* and dijkstra() with axis coordinates could return non-optimal paths (#6385).
• 62 SQL functions and methods threw raw JDK exceptions on missing, negative or wrong-typed arguments ('abc'.substring(), left('abc', -1), range([1], 3)); arguments are validated and reported as HTTP 400 client errors now (#5884, #5885).
• arcadedb.command.timeout now bounds what it claims to. The deadline belongs to the CommandContext, inherited by subqueries, UNION branches and parallel scan workers, and is checked inside openCypher scans, expansions and joins, SQL TRAVERSE/MATCH/filter steps, pathfinding functions, WHERE-less aggregation scans and the vector k-NN path (#6266, #6873).
• Schema probes are free. WHERE 1=0 and LIMIT 0 fold to an EMPTY RESULT step at plan time instead of scanning the target, and WHERE 1=1 folds away instead of being evaluated per record (#6174, #6184).
• SELECT FROM $var mutated the cached statement’s target in place, so a later execution of the same SQL text with a different binding read the first execution’s type (#6669).
• A property DEFAULT that failed to parse was silently stored as its own source text on every record, and re-parsed on every insert; defaults are validated at DDL time and parsed once (#6134).

Graph Engine and Analytical Views

• A Graph Analytical View’s delta overlay is deletion-aware. Deleting one of several parallel edges masked all of them (#6769), an edge created and deleted inside the same overlay window still surfaced as live (#6775), and after a base vertex was deleted the dense node ids could exceed getNodeCount(), so every algo.* procedure silently skipped live vertices (#6792).
• Super-node edge ordering. Once a vertex crossed 4,096 edges its iteration order was silently replaced by the concatenation of 16 hash-striped chains, seen in production as newly created records vanishing from a “newest 100” listing; the stripes are interleaved approximately newest-first now, with arcadedb.graph.supernodeInterleaveRounds degrading to plain concatenation for a full walk (#6044, #6064).
• All 22 superlinear algo.* procedures are abortable and budgeted. An O(V³) run the memory budget admitted ignored Thread.interrupt(), arcadedb.command.timeout and client cancellation (#6302); the graph an algo.* call loads, the embedding matrices and the nodeCount² bitsets are all priced against arcadedb.cypher.algoMaxWorkingMemory now (#6317).
• Two algo.* wrong answers: algo.steinerTree and algo.maxKCut paired edge weights with neighbours by iteration position, so a relTypes filter or the mere presence of a Graph Analytical View produced wrong trees, weights and partitions (totalWeight 1000.0 for a tree costing 2.0) (#6301, #6376). algo.wcc ignored its relTypes argument and algo.degree ignored its direction.

Bulk Load and the Async Executor

• A JSONL batch load silently dropped vertices. 19,484,584 vertex lines in the file, about 17.2 million created, then “Unknown temporary ID” when an edge referenced one of the missing ones (#5618).
• GraphBatch retained 16-18 GB of caches for 100M distinct vertices, forcing a 663M-vertex, 14B-edge gRPC load stream to be recycled every 4M records to keep the server alive; the caches are bounded and deferred incoming edges drained early (#5664).
• The async worker pool stopped being torn down and respawned. setTransactionUseWAL()/setTransactionSync() recreated the whole pool, four times per GraphBatch flush, force-exiting every other user’s queued tasks (2,183 InterruptedIOExceptions in one production log); the flags are plain volatile writes now, and setParallelLevel() resizes in place (#6509, #5665).
• Async writes behave like synchronous ones: updateRecord() never called validate() (#7002), deleteRecord() fired every before- and after-delete listener twice (#7003), and scanType() returned normally when a bucket scan threw (#6467).
• A truncated batch upload applied its records twice, the 409 being the duplicate-key mapping, so a client resuming from the reported counts double-inserted; the interrupted stream commits once and answers 408 with the real counts (#6176).

Backup, Export and Import

• JSONL export and import lost data silently. The exporter wrote DATE values as epoch milliseconds while the importer decoded them as epoch days, so every record with a modern DATE was dropped on import together with its edges (#6455); LINK property values were never remapped, so restored links pointed at unrelated records (#6460); and both sides logged per-record failures and reported success (#6468, #6471).
• Two concurrent backups of the same database wrote the same second-precision path, producing a torn or overwritten archive; backups are serialised per database and the target path claimed atomically (#6753). An auto-backup schedule was never cancelled when its database was dropped or closed (#6752).
• The OrientDB importer parsed every JSON number as double, so LONG values above 2⁵³ were off by one, and it silently dropped composite indexes, losing UNIQUE constraints after migration (#6749, #6750).
• Importing any ZIP source silently yielded 0 records and reported success (#6810), and a user-supplied CSV delimiter was overwritten with null (#6811).

HA and Raft Clustering

• A replica-originated insert lost its unique-index entry on every node. The record committed and replicated cluster-wide, a full scan found it, lookupByKey never did, and a duplicate key could be inserted, because a replica committing its own transaction shipped only the record data (#6964).
• A large, highly compressible bulk transaction crash-looped an entire cluster. It passed the 32 MB submit-time gate measured on the compressed envelope, but its 77,158,147-byte uncompressed WAL exceeded the 64 MB decode ceiling, so every node of a 4/5-node cluster crashed at the same Raft log index on every restart (#5933).
• A snapshot install that gave up on one database still ACKed for all of them, cleared the stale-read floor and let Ratis purge the log, so LINEARIZABLE and read-your-writes reads of the stale database were served from stale state (#6760).
• REST user management did not replicate. POST/PUT/DELETE /api/v1/server/users mutated the user store only on the node that served the request, while the equivalent create user command replicated through Raft, so a user created via REST got 401 on the other nodes (#6808).
• RaftGroupCommitter awaited each entry of a batch with the full quorum timeout sequentially on one thread, so an unresponsive quorum stalled replication for about 83 minutes at defaults (#5848).
• A follower whose log writer hit No space left on device stayed RUNNING while rejecting every append, with nothing short of an operator restart recovering it; the health monitor restarts the server in place once the volume has room (#7037).
• Self-dial loops on single-host clusters are closed. A follower whose derived leader address resolved to itself forwarded every write to itself in an unbounded loop (#6191), localhost and 127.0.0.1 were not recognised as the same endpoint (#6204), and verify could fan out to itself and report ALL_CONSISTENT (#6221).
• CHECK DATABASE FIX works on a cluster. Each per-type repair used to be one unsplittable Raft log entry that aborted at commit on a large database; repairs ship as bounded instalments now (#6128).

TimeSeries

• Bucketed aggregation silently dropped everything appended since the last compaction, because it sized its bucket array from the sealed stores only, so any dashboard query over the newest data was wrong (#6937).
• A TimeSeries type whose sealed store failed to load disappeared from the schema and the database opened as if it had never existed, with the next write creating a fresh empty type; it is registered with its engine unavailable and fails loudly by name now (#6356).
• Under HA, a shard whose sealed store grew past 48 MB stopped sealing for ever, so its samples stayed uncompressed in the mutable bucket with no retention or downsampling; an oversized store ships as ordered slices that followers reassemble and verify, raising the ceiling from 48 MB to roughly 2 GB (#4416).
• PromQL fixes: or returned NaN whenever both sides shared a label set, label matchers on an absent column matched backwards, range points were not step-aligned (#6938), and min_over_time/max_over_time returned ±Infinity for an all-NaN window (#7039).

Wire Protocols

• MongoDB. findOne/updateOne/deleteOne by ObjectId _id never matched (#6745); skip and sort were silently ignored (#6746, #6747); $exists: false returned the documents that had the field (#6748); an upsert filtered on _id discarded it and created a duplicate on every call (#6940); and {field: null} matched nothing (#6952).
• Bolt. A second RUN inside an explicit transaction while the first result stream was open, the normal shape with a driver fetch size smaller than the row count, was rejected as a protocol error (#6804); a property declared ARRAY_OF_FLOATS read back as [F@294b13ce instead of a list, so any client reading embeddings over Bolt got a corrupted string (#7056); and a fragmented WebSocket message had its continuation frames discarded (#6802).
• gRPC. insertStream and bulkInsert ignored the caller’s TransactionContext and committed on their own, so rows survived a subsequent rollback (#6607); errors were flattened to success=false so the client lost the exception type and never retried a conflict (#6192); and a stream longer than txMaxIdleMs was reaped mid-stream and its rows lost (#6755).
• GraphQL. Variables were accepted by the parser but always resolved to null and interpolated into the generated SQL as the literal null (#6834); the standard query($a: String, $b: Int) failed to parse because the comma was a real token (#6860); and field aliases threw an NPE (#6384).
• Redis. Bulk strings were read byte-by-byte as (char) b, mangling any non-ASCII payload (#5907); a RESP2 null bulk string consumed two extra wire bytes and desynced the connection (#5911); and SET ignored all its options (#6466).
• Gremlin. ArcadeGraph.close() committed an open transaction instead of rolling it back, so an aborted unit of work became durable, and a pooled graph was returned to the factory with its transaction still open so the next borrower inherited and committed another caller’s writes (#6820, #6821). The arcadedb-gremlin coordinate was unusable standalone in 26.8.1 (#5879).

Server, HTTP and Console

• A single HTTP response is bounded by a ceiling no caller can widen. httpQueryDefaultLimit protected only callers that stated no limit, so LIMIT 100000000 or "limit": -1 made the server serialise an unbounded result into one JSON response; the new arcadedb.server.httpQueryMaxResultRows (default 1,000,000) refuses with HTTP 413 rather than truncating (#5719).
• The remote client’s watchdog fired after 8h20m instead of 30s, multiplying the millisecond socket timeout by 1000 (#5847), and RemoteGraphBatch.flush() left the payload buffered on failure so close() re-sent it and duplicated committed records (#7031).
• The @props type hint leaked into every response. It appeared in HTTP JSON results for non-element rows, in toJSON(true) and in WebSocket change events broadcast to every subscriber; it is opt-in now through a typeHints request flag, which the Java driver sets automatically (#5812).
• The console dropped every unescaped backslash before the command reached the engine, so a Windows path or a regex literal could not be typed, passed with -b, or replayed with load (#6827); and connect remote: failed on a password containing a space (#6830).
• Kubernetes and Docker quickstarts that could not work. The StatefulSet example used ${VAR} in command:, which is never expanded, so the root password became the literal ${rootPassword} and every pod claimed peer name ${HOSTNAME}, and it wired HA on 2424 while Raft binds 2434 (#6840). The Docker image pinned -Xms2G -Xmx2G, so docker run -m 512m died at startup (#6841).

Upgrade Checklist

No schema migration is required and no existing database is rewritten, but this release contains behaviour changes. Five minutes of checking before you upgrade:

1. Back up first (it is 27.6x faster now), then read the breaking changes in full.
2. Rolling HA upgrade: upgrade followers before, or together with, the leader. A node running an older build cannot install a sliced TimeSeries sealed store (#4416).
3. Grep your schema scripts for out-of-range integral literals. SET n = 3000000000 on an INTEGER property now raises a validation error where it used to store -1294967296. A bulk import carrying such values will surface the error; use the new -onRowError skip to continue past them.
4. Check any HTTP caller relying on limit: -1 or a huge LIMIT to fetch more than 1,000,000 rows in one response: it now gets HTTP 413. Raise arcadedb.server.httpQueryMaxResultRows or set it to -1.
5. Check any client reading @props out of HTTP JSON, toJSON(true) or WebSocket change events: it is opt-in through the typeHints request flag now.
6. After the upgrade, rebuild two things. LSM_TREE indexes written before the #5321 comparator change should be rebuilt; the condition is reported once per logical index as a queryable upgrade warning, visible through schema:indexes and Studio, naming the REBUILD INDEX to run (#5802). Run CHECK DATABASE FIX once to sweep the orphaned chunk slots this release learned to reclaim.
7. If archive size matters more than backup time, set arcadedb.backup.compressionLevel=9 to keep the old ratio.
8. On openCypher, note that “no labels” is a reserved sentinel type ~NO_LABEL~: V and Vertex are ordinary labels now, so labels(n) on a vertex whose only label was V changes on pre-26.9.1 data (#6395).

Dependency Updates

Around 120 dependency bumps landed in this cycle, almost all through Dependabot. The notable ones: the Gremlin shaded jar rebuilt on the project-wide Jackson 2.22.2 so it no longer bundles TinkerPop’s relocated Jackson 2.15.2, Ratis 3.3.0, Netty 4.2.17.Final, Undertow 2.4.3.Final, Lucene 10.5.1, protobuf-java 4.36.0, Logback 1.6.3, snakeyaml 2.7, JLine 4.4.0, Micrometer 1.17.1, OpenTelemetry 1.65.0, Jedis 8.0.1 and the Neo4j Java driver 6.2.1. The Gremlin ANTLR runtime and the Groovy major remain deliberately frozen, as TinkerPop cannot take a newer one.

Getting Started with 26.9.1

Docker

docker pull arcadedata/arcadedb:26.9.1

Visit our Docker Hub repository for more information.

Maven

<dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-engine</artifactId>
    <version>26.9.1</version>
</dependency>

All artifacts are available on Maven Central.

Documentation

For details on features and usage, see the documentation.

Compatibility Note

This release requires no schema migration and rewrites no existing database, so no export or import is needed when upgrading. It does contain behaviour changes, collected in the upgrade checklist above and in full in the release notes. As always, we recommend creating a database backup before upgrading.

Download ArcadeDB 26.9.1 now: GitHub Releases

Thanks to everyone who reported, reproduced, reviewed, tested and fixed, in particular @232-323, @7487, @ajinsads, @altugsogutoglu, @baeseungwon1010, @borutjures, @cakeni, @chow8386, @danieljuhl, @dmoree, @EQSTLab, @FEARIS2, @g33kroid, @gramian, @GYWang1983, @ivan-velikanov, @jjj-n, @josh1e, @justinblethrow-cloud, @kl-demi, @leanworld7-netizen, @LepsyMikolaj3301, @lohithsamaga, @manus-use, @mdre, @NooriUta, @odysseaspenta, @ruispereira, @ruslan-butyk-fntext, @sbsrouteur, @shulei5831sl, @syntact-io-office-user, @T4ran24, @tae898, @tobiasdam, @TobiasJoseHermann, @tonghuaroot, @waterWang, @YGY-001 and @ZwaarContrast.

Luca Garulli ArcadeDB Founder

The headline work is in four places:

• Concurrency: concurrent writes to unrelated records of the same page no longer conflict, which is what made ArcadeDB usable under real multi-writer load on types with few buckets.
• Graph integrity: a family of vertex and edge delete defects that could silently lose edges under concurrency is closed, and deleting a super-node vertex got 5x faster along the way.
• Storage and indexes: bloom filters on compacted LSM series, a schema dictionary that is no longer capped at one page, a geospatial index that costs one entry per point instead of eleven, and TimeSeries TAG columns that are dictionary-encoded.
• Security: 13 advisories closed, most of them on the wire protocols and the MCP endpoint.

Upgrading is strongly recommended for every deployment. There are breaking changes and behaviour changes; no schema migration is required, and no existing database is rewritten.

Major Highlights

Concurrent Writes to Unrelated Records of the Same Page No Longer Conflict

ArcadeDB detects write conflicts per page, so two transactions that touched the same bucket page raised a ConcurrentModificationException even when they wrote completely unrelated records that merely happened to share it. On a type with few buckets and many concurrent writers this made a retry pointless: the retry ran straight into the same collision (#5279).

All three halves of that are gone:

• Inserts into one page reserve their slot per in-flight transaction, so concurrent inserts get different positions (and different RIDs) instead of all being handed the same one.
• Updates are replayed by the commit-time disjoint-slot merge whenever they stayed inside the page, which now includes a record that grew (a longer string, one more property) and not only an overwrite of the same size or smaller. Growth is the normal update shape, so leaving it out kept concurrent updates conflicting.
• Deletes of a plain in-place record are replayed too (#5569). Such a delete only zeroes one slot-table entry, so it commutes with writes to every other slot.

Measured on the reported workload (one single bucket, attempts=1, no retry):

A ConcurrentModificationException is still raised, by design, when two transactions really write the same record: a byte-for-byte pre-image check makes sure no concurrent write is ever silently overwritten. Nothing changes for single-writer workloads and no application change is needed. The merge can be switched off with arcadedb.txPageSlotMerge=false.

The merges also prove their coverage now instead of trusting every writer to declare its pages (#5596): a page carrying even one byte written outside a declared, replayable write is refused and falls back to the ordinary retry. The three merge counters (edgeAppendMerges, txPageSlotMerges, mergesDeclinedByCoverage) are now visible to an operator in the PAGE-MANAGER block, in /api/v1/server, in Studio and on /prometheus (#5608).

Deleting a Vertex No Longer Loses Its Edges, and Is Up to 5x Faster

Four defects, all on the same path, all capable of committing a graph with edges pointing at a vertex that is gone (#5670, #5680, #5725, #5760):

• An edge-list chunk that is momentarily unreadable, a normal MVCC window on a hot vertex rather than a fact about the graph, was read as “nothing to remove here”. The removal ended having removed nothing and the edge record was deleted anyway, leaving a back-reference on a neighbour. It is now a retryable ConcurrentModificationException, so the transaction re-reads a consistent view and completes the removal.
• The same window on the vertex’s own list meant no edges collected, and the vertex record deleted on top of that empty view.
• An edge appended while the delete was running survived the delete with a live out and an in naming a record that no longer exists. A vertex delete now pins every page its edge list can grow through, at the version it read the list at.
• Each edge was disconnected from both endpoints, one of which is always the vertex being deleted, whose lists are dropped wholesale moments later. Each edge is now disconnected from its far end only.

That last one is also where the performance is. 100k edges into one hub, on an Apple M-series laptop:

The removal walk streams now: deleteVertex no longer materialises every edge into a list first, so there is no per-degree allocation on the path at all (tens of megabytes of retained heap on a million-edge super-node).

Visible effect. vertex.delete() / DELETE VERTEX and edge.delete() / DELETE EDGE can now raise a retryable ConcurrentModificationException where they previously “succeeded” while losing an edge. It is a NeedRetryException, so database.transaction(...) and the server’s auto-retry for single-request commands absorb it. A client-managed explicit transaction over RemoteDatabase spans several HTTP requests, so its commit is not auto-retried and the caller should retry the transaction. A delete that keeps failing however often it is retried means the list is genuinely broken: the error now names the repair, CHECK DATABASE RECORD #12:3 FIX, and the retry after it goes through.

Bloom Filters on Compacted LSM Indexes (Enabled by Default)

An LSM index lookup walks every compacted series from newest to oldest, and a series whose key range covers the key still costs a root-page search and a data-page read to discover it does not hold it. Each compacted series now carries a bloom filter that answers from a single 8 KB page (#5517).

Measured on 2M keys across 9 series (LSMTreeBloomFilterBenchmark):

• On by default at a 1% target false-positive rate: arcadedb.indexBloomFilterRate=0.01. Set 0 to disable.
• ~1.2 bytes per key on disk, about 3% of the index it describes, in a <index>_bf.bfidx component.
• No rebuild and no migration. Filters are written by compaction, so an existing index gains them at its next compaction. They replicate over HA and are included in backups.
• Helps most when compacted series overlap in key range: an email, a UUID, a business id. Ascending keys give each series a disjoint slice the root page already rules out. Range scans never consult them.
• Observability: bloomSkippedSeries and bloomProbedSeries in the index statistics.

Backward and forward compatible with no version bump: an older ArcadeDB does not recognise the .bfidx extension and reads the index exactly as it does today.

The Schema Dictionary Is No Longer Capped at a Single Page

Every type and property name is mapped to a small integer id, and that table lived in one page: 48,396 short names measured. Past it, CREATE PROPERTY and inserting a document with a new field name failed permanently with No space left in dictionary file, with no way to grow and no way back (#5560).

Names now roll over onto further pages, so the cap is gone.

• No migration, and existing databases are not rewritten. A dictionary written by an earlier version is a dictionary of one page and loads unchanged; it gains rollover on the next write that needs it.
• Appending a name is no longer quadratic. Growing to 500,000 names took 11.2s of pure array copying; it now takes 2ms.
• New databases use a 65,536-byte dictionary page instead of 327,680, so a new name dirties and flushes 5x less. Existing databases keep the page size they were created with.

Rolling upgrade: upgrade followers before, or together with, the leader. Dictionary pages replicate as raw pages, and a follower on an older build writes page 1+ but reloads only page 0. A database that has rolled over can no longer be opened by an older ArcadeDB at all, loudly rather than silently.

Geospatial Index: a Point Costs One Entry Instead of Eleven

A GEOSPATIAL index stored the whole GeoHash ancestor chain, so a single point wrote one entry per tree level, 11 by default. Everything an index write costs was multiplied by 11, and the continent-sized cells at the top of the tree collected one posting per record and grew without bound, which is why a bulk load with a geospatial index got slower the longer it ran and finally failed with ReplicatedEntryTooLargeException (#5478).

On an LSM-Tree, “every cell below C” is simply a key range, so the ancestors do not need to be materialised. The index now stores only the frontier cells, exactly one for a point, and answers a query with a prefix range scan. On a 1M-point load into one country-sized box (GeoIndexIngestBenchmark):

The index costs 5.3x less, the whole load is 1.7x faster, and the index is 11x smaller on disk. Area shapes index fewer cells still: a complete set of sibling cells collapses into its parent, 57% fewer for a small square and 74% for a jagged outline. Queries are also more selective and stream their candidates instead of materialising the whole set, and a POINT search shape now uses the index at all (geo.equals / geo.contains used to find nothing and fall back to a full scan).

Existing indexes keep working and are not rewritten: the layout is recorded per index. Opening the database says so once per index, and Studio shows a banner with the ready-to-run statement: REBUILD INDEX `Address[location]`. Note the shapeRel half of the fix lives in the shared query walk, so an index still on the old layout also stops skipping covering cells the moment the jar is swapped.

TimeSeries TAG Columns Are Dictionary-Encoded: 36x Less Page Traffic

A TimeSeries mutable row is fixed-stride, so a STRING TAG column reserved 258 bytes whether the tag was us-east-1 or empty. Tags are low-cardinality by definition, so nearly all of that was padding that still had to be written, flushed and shipped through the WAL (#5519).

A TAG column now holds a 4-byte id into a per-type append-only dictionary component:

The ten-tag arm went from writing 50.0 MB of pages for 2.1 MB of payload (23x amplification) to 1.4 MB (0.7x), and from 29.9 ms to 6.0 ms. Corroborated independently on real TSBS data (2,592,000 points) by @tae898 in the issue.

• arcadedb.timeSeriesTagDictionaryMaxSize caps distinct values per type, default 1M.
• STRING fields stay inline: a field is where high-cardinality text belongs.
• Existing types keep the inline layout. The row format is versioned per type; a new TimeSeries type gets the encoding, an existing one has to be recreated to gain it. If you are benchmarking, point the harness at a fresh database or you will measure the old layout.

MCP: a Module of Its Own, New Tools, and Per-Principal Scoping

The MCP server is now a dedicated arcadedb-mcp module (#5692) and gained the tool surface that makes it usable as a GraphRAG back-end:

• vector_search (dense and sparse), hybrid_search, full_text_search and a bounded sample_records (#4860, #4861, #4862, #4863).
• Prompts graphrag_query and build_knowledge_graph, the latter with an enforceable source-text fence (#4866, #5586).
• Configurable tool profiles, per-database permission scoping and per-principal profiles on a shared endpoint (#4867, #4868, #5445).
• MCP 2025-03-26 transport conformance: batches, notifications, GET and Origin handling (#5394), plus proper JSON-RPC -32602 for malformed members instead of HTTP 500 (#5585, #5620).

Much of this arrived from @justinblethrow-cloud.

Experimental: GraalVM Native-Image Build of the Server

An experimental native-image build of the ArcadeDB server is now part of the build (#5544): a single self-contained binary with no JVM start-up cost. Experimental means exactly that, it is not yet part of the published distribution.

Security Advisories

This release closes 13 security advisories, on top of the three closed in 26.7.3. Each is published in full (impact, affected versions and credit) as a GitHub Security Advisory on the repository; the summaries below are only a map of what changed. Upgrading is strongly recommended for any deployment that exposes a wire protocol, the MCP endpoint, or accepts queries from untrusted callers.

Authentication and authorization on the wire protocols

• GHSA-fq9c-x968-g278: the MongoDB protocol accepted commands without authenticating the caller. It now authenticates and enforces per-database authorization.
• GHSA-m46c-jh3x-xwrp: the Redis protocol required no authentication. It now requires AUTH, supports the HELLO handshake, and can be served over TLS.
• GHSA-c287-v325-j5jx: the Gremlin protocol did not enforce per-database and per-type authorization.

The authenticated principal is now bound on every execution path

The engine’s per-user permission gates are deliberately no-ops when no principal is bound on the thread, which is how embedded and replication contexts skip them. Three paths reached the engine without binding it, so every gate silently passed:

• GHSA-p29f-345w-4qwf: the gRPC transaction thread.
• GHSA-5j4x-3jfw-8xv3: the async command worker thread.
• GHSA-c23x-pqcj-7hfm: the batch and time-series HTTP handlers, so per-type ACLs did not enforce.

Privileged operations that were not gated

• GHSA-pff6-hp53-pj54: the server-administration MCP tools (set_server_setting and the profiler controls) gated only on the global allowAdmin flag and ignored the caller. They are root-only now, matching POST /api/v1/server.
• GHSA-vv82-qvpf-rjwv: DELETE FUNCTION did not require UPDATE_SCHEMA.
• GHSA-hfp5-6gcp-8c75: Cypher LOAD CSV could read local files without administrative privilege.
• GHSA-qwgr-2c45-63xx: the database name was not validated when creating or dropping a database, allowing path traversal outside the configured database directory.

Untrusted input reaching the host

• GHSA-4w2m-77c8-83mw: a caller-supplied URL was validated only on its first hop and re-resolved after the check, so a redirect or a DNS rebind could reach an address the validation had rejected (SSRF). Every hop is validated now, and the validated address is pinned for the duration of the fetch.
• GHSA-wx28-2265-f788: the scripting host-class allow-list was matched as a regular expression, so an entry could admit far more classes than it names. It is matched literally now.
• GHSA-xmjm-8q85-g778: range() materialised every element, so one query could exhaust the heap. The list is lazy now and a range beyond arcadedb.queryMaxRangeSize is refused as a client error.

Also hardened in this release

• MongoDB protocol: field names and filter values can no longer inject SQL. A MongoDB command is translated into SQL, and the field names and values taken off the wire were embedded without escaping. A filter value containing a single quote closed the string literal, so an updateMany with a crafted name updated every document; a $unset / $inc field name containing a back-tick removed a property the client never asked for. Values are now bound as parameters and every field name is back-tick quoted, one dot-separated segment at a time (#5579, #5583).
• Server and cluster status endpoints scope their per-database output to the caller. GET /api/v1/cluster, the ha.databases array of GET /api/v1/server?mode=cluster and the metrics.sparseVectorIndexes map now reduce every per-database entry to the databases the caller is authorized for. POST /api/v1/cluster/bootstrap-state and GET /api/v1/cluster?presence=true move behind the root check the seven mutating Raft endpoints already use.
• Studio no longer carries schema names in inline onclick handlers (#5580).

New Features

Storage and Indexes

• CHECK DATABASE RECORD <rid>: check and repair named records only, instead of two full passes over a type (#5680). Combines with FIX and COMPRESS.
• CHECK DATABASE FIX reclaims orphaned edge-list segments (#5375), and rebuilds unreadable edge lists from the surviving edge records.
• Live progress for CHECK DATABASE, REBUILD INDEX, COMPACT INDEX, BACKUP DATABASE and IMPORT DATABASE, in the engine, over HTTP, in the console and in Studio (#5372, #5376).
• COMPACT INDEX is reachable from SQL/HTTP, not only from the Java API (#5144).
• GEOSPATIAL indexes have a builder of their own, so precision and tokenization are settable from SQL: CREATE INDEX ON Location (coords) GEOSPATIAL METADATA {"precision": 6}.
• An LSM_VECTOR index compacts itself once its file is mostly garbage (#5516).

• HASH indexes can key on a LINK, so an edge type’s @out/@in pair can be indexed UNIQUE_HASH, the structural way to enforce edge de-duplication, which used to be accepted and then fail on every insert claiming page corruption (#5677):

  CREATE INDEX ON INITIATED (`@out`, `@in`) UNIQUE_HASH
  

Server and Operations

• Opt-in SLF4J logging. Slf4jLogger routes ArcadeDB’s logs through the SLF4J facade instead of writing to stdout, keeping java.util.logging as the default, so an embedding host application gets consistent logs (#4276). arcadedb.log.impl is now a proper GlobalConfiguration entry (#5543). Contributed by @ruispereira.
• The OpenAPI spec matches the registered HTTP route surface (#4895).
• arcadedb.server.httpQueryDefaultLimit makes the HTTP row cap configurable (default 20000, -1 for unlimited), and truncated responses say so.

Query Engines

• Parallel top-K for LSM_SPARSE_VECTOR: a sparse top-K is split into parallel RID ranges (#4085), 3.4x on real SPLADE data.
• Cypher CREATE CONSTRAINT ... IS UNIQUE / IS NODE KEY upgrade a plain index in place, so a Neo4j migration script that creates indexes and then constraints keeps working.

Major Fixes and Improvements

Bulk Load

• A failed bulk load answers immediately instead of waiting for the rest of the upload. POST /api/v1/batch rejects a payload it cannot use, but did so only after reading the rest of the upload, so on a 25M-line load the client was told nothing for fifteen minutes and then nothing at all (UT000002: The response has already been started). The verdict is now delivered as soon as it is reached (#5470).
• GraphBatch.close() restores the configured WAL flush, not the default, so durability is no longer silently downgraded after any bulk load (#5378).
• Two concurrent GraphBatch instances on the same database are refused instead of silently losing edges (#5666).
• Time-series HTTP ingest batches into one append transaction per measurement.

Graph Engine

• Deleting an edge no longer leaves its back-reference behind under concurrency, on all three operations that disconnect one: DELETE EDGE, moving an edge, and DELETE VERTEX (see the highlight above).
• Ghost-edge pruning during iteration no longer rolls back and replaces the caller’s transaction (#5694).
• TX_RETRY_DELAY is read from the database configuration instead of the global static, so a per-database override applies (#5693).
• Broken multi-page records are deletable again by every path, and CHECK DATABASE FIX repairs them.

Indexes

• countEntries() no longer counts tombstones as live entries. Deleting every record of a type left the index reporting 1 with zero records in the database (#5601).
• An index cursor never hands out a null entry, hasNext() is exact, next() throws NoSuchElementException once exhausted, and getRecord() / getKeys() describe the entry next() last returned (#5635). Two user-visible consequences fixed with it: SELECT min(...) / max(...) could answer with a deleted key, and a delete-heavy index reported one entry too many.
• Cursor is AutoCloseable, and a leaked cursor no longer pins a retired index file for the lifetime of the database (#5662).
• A HASH index refuses a page size its bucket pages cannot address. Above 65536 bytes the 16-bit slot offsets truncate and the index destroys itself on insert, reported as Detected cycle in hash index (#5713).
• Partitioned types, three fixes. A lookup on a secondary index was pruned to the bucket the lookup key hashed to rather than the partition key’s, so a secondary UNIQUE index stopped rejecting duplicates (#5589). A lookup key boxed differently than the stored value hashed differently, so on a LONG partition key every negative value missed (#5595). And a partition key whose bucket is not a function of the index key (BINARY, DECIMAL, zone-carrying DATETIME, COLLATE CI) is now refused instead of quietly breaking UNIQUE (#5603). The strategy is also persisted now (#5637).
• CREATE INDEX IF NOT EXISTS answers for the index asked for. It matched on the property set alone, so a NOTUNIQUE index answered “already there” to a request for a UNIQUE one and the constraint was never created (#5675, #5765).
• An existing index is never dropped implicitly any more. Opt in with withReplaceIfIncompatible(true).
• Manual indexes work. ManualIndexBuilder.create() registered the wrong object, so the very next commit fenced the database (#5765).
• Copying a type copies its records and its index definitions, not just their names (#5723).
• REBUILD INDEX no longer resets a non-default GeoHash precision, and an index METADATA key is now either applied or reported (#5639); four dense-vector settings that were unreachable behind that silence (efSearch, inactivityRebuildTimeoutMs, neighborOverflowFactor, alphaDiversityRelaxation) are now settable and persisted.
• Full-text BM25 is comparable across buckets (#5267), and a combined full-text index expands per property (#5181).
• Bounded range scans over multi-series compacted indexes no longer drop rows or mis-order descending results (#5214), an accented partial prefix no longer returns rows of other keys (#5321), and a mixed-type index range is bounded by type category (#5225).
• A STRING property no longer reads back as a geometry. Deserializing any string whose first characters were POINT, POLYGON and so on parsed it as WKT and handed back a Shape (#5600).

Vector Search

• A search aimed at a deleted region finds the survivors instead of nothing. Two independent causes: the traversal was told every node was an acceptable answer, so a beam that filled with tombstones declared itself finished; and a tombstone was scored through a placeholder vector whose cosine similarity came back Infinity, making every tombstone the best candidate in the beam (#5558).
• countEntries() is no longer torn by a concurrent graph rebuild (#5568).
• The location cache is gone and locationCacheSize is refused. It was never a cache bound: an evicted location is unrecoverable and every reader reads a missing location as deleted, so a cap of 100 over 1000 live vectors made countEntries() report 100 and dropped neighbours from searches (#5559).
• In-memory bloat is fixed: VectorLocation objects were never removed from the map, an OOM after weeks of operation (#5516), and LSMVectorIndex.remove() no longer scans every vector id per call (#5318).
• A committed vector is no longer intermittently missing from search (#5615), and GraphSearcherPool can no longer hand out a searcher bound to a replaced graph (#5648).
• Sparse vectors: compaction no longer fails past the 2GB WAL buffer (#5189), the top-K heap no longer allocates a Float on every comparison (#5473), and block-max skipping cuts the p50 that tracked total posting length (#5388).
• Studio can create a vector index (#5607), and dimensions is now enforced at creation: an index created without it accepted writes and indexed nothing, forever, without a warning.

TimeSeries

• DATE / DATETIME_* / DECIMAL / BINARY fields no longer silently corrupt the next column, and the sealed layer restores the declared column type (#5475).
• Unbounded last-point-per-tag no longer scans the whole series (208 ms to 2.5 ms) via a per-shard latest-ts shortcut (#5414), and an unbounded descending scan no longer reads the whole unsealed tail (#5416).
• Ingest no longer boxes every numeric sample (#5474).

HA / Raft Clustering

• A materialized view no longer makes the leader ship page versions followers never received (#5492), the WALVersionGapException / non-converging-resync / lost-write shape. Both SQL and Cypher statements now execute against the replicated database instance rather than the inner LocalDatabase (#5655).
• A follower’s index can no longer be short after an LSM compaction, which silently returned fewer rows (#5443).
• Concurrent transactions on a shared follower Database handle no longer corrupt records or lose committed writes (#5503).
• A leader crash between the Raft commit and the phase-2 apply no longer loses a locally-originated write (#5407), and the phase-2 ticket is released when an abandoned entry applies (#5410).
• The Raft log no longer grows unbounded until disk-full on low-write clusters (#5345), and a permanently wedged follower replication channel now escalates instead of staying dead until a leader restart (#5346).
• The leader is no longer advertised as available before it is ready to serve (#5453), and DROP DATABASE no longer deletes files synchronously inside the Raft apply (#5454).
• Kubernetes: a recreated follower is no longer permanently stranded (#5268), a peer is no longer silently removed from the Raft configuration when its pod is deleted (#5275), a stranded follower’s Raft server is no longer left CLOSED (#5271), the crash-loop on newTI < oldTI is gone (#5291), and the default raftStorageDirectory lands inside server.databaseDirectory (#5272, #5277).
• Cluster status is accurate: the configuration is re-emitted rather than logged once at bootstrap (#5304), the LATENCY column reports replication RTT rather than heartbeat age (#5314), a never-appended follower is no longer reported HEALTHY (#5295), and POST /api/v1/cluster/leader validates its body (#5276).
• Polymorphic count(*) FROM V no longer returns node-dependent totals from bucket counter drift (#5297), and parameterized Gremlin commands work on followers (#5187).
• A failed startup no longer leaves an unkillable JVM (#5450), non-daemon background threads no longer keep an embedder JVM alive after a leaked Database (#5418), and schema.load() no longer runs before checkForRecovery() (#5325).

OpenCypher

• A hop onto an already-bound vertex counts every relationship joining the pair. The optimizer’s operator for such a hop was built as a semi-join, so it answered once per input row and threw the rest of the pair away. The shape where it shows is a cycle, whose closing hop always has both endpoints bound: anything aggregating over such a pattern under-reported wherever parallel edges exist between a pair, which is normal in transaction and payment graphs (#5663). Row counts can go up, and that is the fix.
• An unbound $parameter is an error, not null. A query referencing a $name the caller never bound evaluated it to null and ran to completion against a value nobody supplied, so a de-duplicating WHERE NOT EXISTS { ... } CREATE guard degraded into an unconditional CREATE. ArcadeDB now raises Neo4j’s own Expected parameter(s): id (#5501, #5561).
• A subquery body is part of the query, not a string it carries. EXISTS { }, COUNT { } and COLLECT { } held their body as text, edited it once per outer row to correlate it, ran it as a standalone statement and absorbed any failure into the expression’s neutral value (false, 0, []) (#5656, #5657, #5658). Bodies are ASTs now, run with the outer row as a seed, and a failing body is reported (#5626).
• A non-numeric argument to abs() and friends is a 400, not a 500 (#5484, #5602), with the message phrased in the vocabulary of the language: Type mismatch: abs() expects an INTEGER or a FLOAT argument but got STRING.
• Arithmetic errors are client errors. 64-bit overflow, division and modulo by zero answer HTTP 400 and Bolt’s Neo.ClientError.Statement.ArithmeticError (#5545, #5647). Floating-point is untouched.
• The two count push-downs agree. RETURN count(*) LIMIT 0 returned a row; a pattern that cannot match cost 200 record reads to answer 0; MATCH (a)-[:LINKS]->(b) RETURN count(*) with an unlabelled anchor answered 0 (#5715, #5686).
• Inline WHERE predicates apply everywhere they are written: in MATCH, in EXISTS { }, in pattern comprehensions, on variable-length patterns and in both shortestPath evaluators (#5460, #5462, #5463, #5464, #5480, #5481, #5489, #5490).
• Planner: an inline property map is planned as the equality predicate it stands for (#5446); a bound-target expansion filters on the segment’s neighbour pointer (#5660); composite indexes are seeked by their whole key (#5444); and bounded variable-length paths use indexed and IN-list anchors (#5357, #5387, #5393).

SQL

• Integer arithmetic fails on overflow instead of wrapping, and division by zero is a client error (#5164, #5647, #5494).
• Back-tick quoted names containing a backslash are no longer mis-parsed. A name that arrived already escaped grew one backslash on every parse and re-emission until it no longer resolved.
• MATCHES works when the regular expression contains multiple dots (#5258), the MATCH rid filter is no longer discarded (#5315), and TRAVERSE/SELECT from a bound RID collection no longer NPEs (#5505).
• UPDATE ... MERGE supports parameterized payloads (#5347).
• A large batch script no longer dies with StackOverflowError when closing its execution plan (#5708, #5720).
• ceil()/floor() return FLOAT (#5382), || rejects non-STRING operands (#5298), chained comparisons are honoured (#5284), split() with an empty delimiter no longer appends a spurious element (#5390), and datetime(map) honours epochSeconds/epochMillis (#5274).
• dateTimeImplementation=java.time.Instant no longer breaks reading DATETIME values. The moment a DATETIME column crossed the JSON boundary it threw UnsupportedTemporalTypeException: Unsupported field: YearOfEra, which took out HTTP, the remote driver, Studio, toJSON() and the SQL .format() method.

Server, HTTP and Observability

• A truncated query response is no longer indistinguishable from a complete one. The HTTP endpoints serialize at most 20,000 rows and reported that nowhere: same 200, same body shape (#5711). A limit the caller states is now honored as written, a query’s own LIMIT raises the cap, and the response carries {"limit": 20000, "returned": 20000, "truncated": true}. RemoteDatabase.setMaxResultRows(Integer) sets it per connection; Studio marks the row count (truncated).
• Query and HTTP metrics survive an in-process server restart (#5565).
• Unexpected internal server errors stay visible in production-mode logs (#5374), with the full stack trace.
• HTTP status classification: client errors are classified on the Postgres, Redis, MongoDB and GraphQL wire paths (#5628), the command API no longer answers 500 ClassCastException for a non-string language or command field (#5222), and JSON array payloads are accepted (#5415).
• The “not found” message for a missing bucket reaches the user again (#5636). Schema now exposes null-returning getBucketByIdIfExists(int) / getBucketByNameIfExists(String).
• The remote driver honors the server’s 503 “please retry”, and the console no longer terminates a comment on a semicolon (#5457).

Wire Protocols

• PostgreSQL: quoted identifiers are identifiers, not string literals (#5369); the schema path no longer collapses ARRAY_OF_* / DATETIME_* to VARCHAR (#5311); LIST OF EMBEDDED is advertised as json[] (#5289); nested arrays serialize (#5366); and a single-column projection no longer returns every column (#5367).
• Gremlin: a traversal result carrying a raw RID serializes (#5309); ArcadeGraphManager no longer caches a stale graph after the underlying database is reopened (#5307); hasLabel() no longer returns elements of the wrong kind (#5223).
• Bolt: two concurrency defects behind the flaky concurrentSessions are fixed, and a missing parameter answers Neo.ClientError.Statement.ParameterMissing rather than SyntaxError.

Breaking Changes and Upgrade Notes

No schema migration is required and no existing database is rewritten. The items below change behaviour that existing code or scripts may depend on. The full list is in the release notes.

SQL and Cypher

• Inside a back-tick quoted name, a backslash escapes the next character. A literal backslash has to be doubled. Only names that actually contain a backslash are affected.
• Cypher: an unbound $parameter raises Expected parameter(s): x instead of evaluating to null. To keep the old behaviour for a specific query, bind the name explicitly to null.
• Cypher: a failing EXISTS { } / COUNT { } / COLLECT { } body returns its error instead of the expression’s neutral value. The old answer was wrong, not merely quiet.
• Cypher: parse-time validation reaches every clause and every subquery body. A query whose bad call sits in a clause the validation never walked, or in a branch that never executes, is now rejected before it starts.
• Cypher: a wrong argument count now raises CommandSemanticException (a CommandParsingException subclass). Embedded code catching CommandExecutionException around a call should catch CommandParsingException.
• Cypher: row counts can go up where parallel edges join a pair and the pattern has a hop onto a bound vertex (typically a cycle). A saved report or a threshold calibrated against the old numbers should be re-checked.

Indexes

• CREATE INDEX ... METADATA refuses an unknown or malformed key, on LSM_VECTOR, LSM_SPARSE_VECTOR and FULL_TEXT. A stored migration carrying a stray or misspelled key used to run and is now refused, which is the point, since the key was never doing anything.
• A guarded CREATE INDEX IF NOT EXISTS naming a setting may now raise where it used to be a no-op, if the index already there carries a different value for any key the clause names. Drop the keys you do not actually require, or align the value.
• An existing EUCLIDEAN or DOT_PRODUCT vector index changes its search results on the first reopen. The persisted definition names the metric similarityFunction while the reader looked only for similarity, so such an index has been scoring with COSINE since the first restart after it was created. It now scores with the metric it was created with. Nothing to re-create or rebuild. COSINE indexes are unaffected.
• arcadedb.vectorIndex.locationCacheSize and the per-index locationCacheSize metadata are refused for any positive value. Remove the key from any CREATE INDEX script before upgrading. Plan for ~90 bytes per live vector, the figure getStats() now reports as estimatedLocationIndexBytes.
• getOrCreateTypeIndex no longer upgrades an incompatible index: it raises IllegalArgumentException naming both definitions instead of dropping and rebuilding. Use buildTypeIndex(...).withReplaceIfIncompatible(true) if replacing really is what you mean.
• withPageSize(0) now means “use the default”, and withPageSize(262_144) on a HASH index is now refused with a message naming the 256-65536 range.
• A LINK HASH index created with this release is not readable by an earlier build. It has to be dropped before downgrading.

Metrics and Reported Statistics

• The monotonic engine metrics are Prometheus counters now, so the exported series are renamed with a _total suffix: arcadedb_engine_page_cache_hits_total, arcadedb_engine_pages_read_total, arcadedb_engine_wal_bytes_written_total, arcadedb_engine_mvcc_conflicts_total, arcadedb_engine_queries_total and the rest. Existing dashboards and alerts on the old names need updating. The three genuinely instantaneous readings (wal_files, files_open, databases) stay gauges and keep their names.
• A server restart in the same JVM resets the query and HTTP counters, because the values belong to the server that recorded them.
• CHECK DATABASE output changed: a corrupt vertex or edge produces one warning per record instead of two, and totalWarnings now counts distinct messages rather than occurrences.

Java API

• Schema gains getBucketByIdIfExists(int) and getBucketByNameIfExists(String), source-incompatible for anyone implementing com.arcadedb.schema.Schema outside the project.
• AfterRecordReadListener must return a mutable record when returning a different one than it was handed (typically record.modify()) (#5755).
• BucketLSMVectorIndexBuilder no longer exposes its settings as public fields. Every fluent withX() method is preserved, with withEfSearch added.
• TypeLSMVectorIndexBuilder.withLocationCacheSize(N) is deprecated and refuses a positive N.
• BucketSelectionStrategy.getBucketIdByKeys(List, Object[], boolean) is the new contract; the single-argument form and DocumentType.getBucketIndexByKeys(Object[], boolean) are deprecated and never prune.

Operational

• Partitioned types: a database that ran partitioned(...) on a type carrying more than one index may already hold duplicates in a secondary UNIQUE index. The constraint is enforced again from this release, but existing rows are not retro-validated: check those indexes and REBUILD INDEX them.
• Geospatial: existing indexes keep the old layout and are not rewritten, but they change query behaviour the moment the jar is swapped. Run REBUILD INDEX `Type[prop]` to get the ingest and selectivity gains.
• Rolling HA upgrade: upgrade followers before, or together with, the leader, because of the multi-page schema dictionary.

Dependency Updates

Around 80 dependency bumps landed in this cycle, almost all through Dependabot. The notable ones: the Jackson family pinned to 2.22.1 via jackson-bom, Ivy raised to 2.6.0 to clear CVE-2026-26032, GraalVM 25.2.4, JVector 4.0.0-rc.9, Groovy 4.0.33 and Logback 1.6.1. Two versions are deliberately frozen and documented as such: the Gremlin ANTLR runtime and Groovy majors, which TinkerPop cannot take.

Getting Started with 26.8.1

Docker

docker pull arcadedata/arcadedb:26.8.1

Visit our Docker Hub repository for more information.

Maven

<dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-engine</artifactId>
    <version>26.8.1</version>
</dependency>

All artifacts are available on Maven Central.

Documentation

For details on features and usage, see the documentation.

Compatibility Note

This release requires no schema migration and rewrites no existing database, so no export or import is needed when upgrading. It does contain behaviour changes, collected in the section above. As always, we recommend creating a database backup before upgrading.

Download ArcadeDB 26.8.1 now: GitHub Releases

Thanks to everyone who reported, reproduced, reviewed, tested and fixed, in particular @adepase, @alphafarmer, @borutjures, @cmettier, @danieljuhl, @focusmacula, @gramian, @ironluca, @ivanfrias, @justinblethrow-cloud, @kl-demi, @KyaniteSolutions, @LepsyMikolaj3301, @mdre, @rthuffman, @ruispereira, @Rupert1987, @shulei5831sl, @sunil-pateel, @tae898, @TobiasJoseHermann, @vivekjustthink, @waterWang, @xdevsapps and @YaeSakuraQ.

Luca Garulli ArcadeDB Founder

Everything here runs in-process with pip install arcadedb-embedded. No server, no separate vector database.

What Agent Memory Actually Is

“Memory” gets used loosely. In practice an agent needs three different things, and only two of them belong in a database.

Working memory is the context window: the current conversation, tool outputs, and scratchpad. It lives in the prompt and disappears when the request ends.

Episodic memory is what happened. Turn by turn, session by session: the user asked X, the agent called tool Y, the result was Z. It is append-only and inherently temporal.

Semantic memory is what the agent has learned. Durable facts about entities: this user prefers Postgres, this project depends on that service, this customer is on the enterprise plan. Facts change, and the changes matter.

The common mistake is to implement all three as a single vector index over conversation transcripts. That works for the first demo and degrades quickly.

Why a Vector Store Alone Is Not Enough

Embedding every turn and retrieving the top-k nearest is a reasonable baseline. It fails in four specific ways, and all four are relationship problems.

Superseded facts. The user said they work at Acme in March and at Globex in June. Both turns are in the index, both are semantically similar to “where does the user work”, and the retriever has no notion that one replaced the other. The agent confidently returns the wrong employer. A vector index has no concept of validity.

Entity identity. “Ana”, “Ana Ruiz”, and “a.ruiz@example.com” are the same person. Cosine similarity does not know that. Without entity resolution, memory fragments across aliases and recall silently degrades as the number of sessions grows.

Structural questions. “What has this user asked about the billing service?” is a filter over a relationship, not a similarity search. A vector index can only approximate it, and approximation is exactly the wrong tool when the answer is deterministic.

Multi-hop recall. “Which of the user’s projects depends on the library that just broke?” requires traversing project to dependency to incident. No single stored turn contains that chain.

A knowledge graph answers all four directly, because it stores the relationships instead of hoping similarity implies them. What it is not good at on its own is fuzzy recall, which is why the useful design keeps both, in one engine.

The Schema

Four vertex types and three edge types are enough to start.

import arcadedb_embedded as arcadedb

DIM = 1536  # match your embedding model

db_ctx = arcadedb.create_database("./agent-memory")

with db_ctx as db:
    with db.transaction():
        # An episode is one thing that happened
        db.command("sql", "CREATE VERTEX TYPE Episode")
        db.command("sql", "CREATE PROPERTY Episode.content STRING")
        db.command("sql", "CREATE PROPERTY Episode.session STRING")
        db.command("sql", "CREATE PROPERTY Episode.ts DATETIME")
        db.command("sql", "CREATE PROPERTY Episode.embedding LIST OF FLOAT")

        # Entities the agent has learned about
        db.command("sql", "CREATE VERTEX TYPE Entity")
        db.command("sql", "CREATE PROPERTY Entity.name STRING")
        db.command("sql", "CREATE PROPERTY Entity.kind STRING")
        db.command("sql", "CREATE INDEX ON Entity (name) UNIQUE")

        # A durable fact, valid over an interval
        db.command("sql", "CREATE VERTEX TYPE Fact")
        db.command("sql", "CREATE PROPERTY Fact.predicate STRING")
        db.command("sql", "CREATE PROPERTY Fact.value STRING")
        db.command("sql", "CREATE PROPERTY Fact.valid_from DATETIME")
        db.command("sql", "CREATE PROPERTY Fact.valid_to DATETIME")

        db.command("sql", "CREATE EDGE TYPE MENTIONS")   # Episode -> Entity
        db.command("sql", "CREATE EDGE TYPE ASSERTS")    # Episode -> Fact
        db.command("sql", "CREATE EDGE TYPE ABOUT")      # Fact    -> Entity

        # HNSW index for semantic recall over episodes
        db.command("sql",
            f"CREATE INDEX ON Episode (embedding) LSM_VECTOR "
            f"METADATA {{ dimensions: {DIM}, similarity: 'COSINE' }}")

The separation matters: an Episode is immutable and says what was observed, a Fact is the interpretation, and the ASSERTS edge records which episode produced it. When the agent later gets something wrong, you can trace the belief back to the turn that caused it.

Writing a Turn to Memory

Each turn does three things: store the episode with its embedding, resolve the entities it mentions, and assert or update any facts.

from datetime import datetime, timezone

def remember(db, session, text, entities, facts):
    """Persist one turn: episode, entities, and any facts it asserts."""
    now = datetime.now(timezone.utc).isoformat()

    with db.transaction():
        db.command("sql",
            "CREATE VERTEX Episode SET content = ?, session = ?, "
            "ts = ?, embedding = ?",
            text, session, now, embed(text))

        for name, kind in entities:
            # UPSERT gives one vertex per distinct entity name
            db.command("sql",
                "UPDATE Entity SET name = ?, kind = ? UPSERT WHERE name = ?",
                name, kind, name)
            db.command("sql",
                "CREATE EDGE MENTIONS "
                "FROM (SELECT FROM Episode WHERE content = ? AND session = ?) "
                "TO (SELECT FROM Entity WHERE name = ?)",
                text, session, name)

        for subject, predicate, value in facts:
            assert_fact(db, subject, predicate, value, now, source=text,
                        session=session)

Keeping Facts Current Without Losing History

This is the part a vector store cannot do at all. When a new value arrives for a predicate that already has one, do not overwrite it: close the old fact and open a new one.

def assert_fact(db, subject, predicate, value, now, source, session):
    """Close any currently-valid fact for this predicate, then open a new one."""
    # 1. Invalidate the previous value, if any
    db.command("sql",
        "UPDATE Fact SET valid_to = ? "
        "WHERE predicate = ? AND valid_to IS NULL "
        "AND @rid IN (SELECT in('ABOUT').@rid FROM Entity WHERE name = ?)",
        now, predicate, subject)

    # 2. Record the new value
    db.command("sql",
        "CREATE VERTEX Fact SET predicate = ?, value = ?, valid_from = ?",
        predicate, value, now)
    db.command("sql",
        "CREATE EDGE ABOUT "
        "FROM (SELECT FROM Fact WHERE predicate = ? AND value = ? "
        "      AND valid_to IS NULL) "
        "TO (SELECT FROM Entity WHERE name = ?)",
        predicate, value, subject)
    db.command("sql",
        "CREATE EDGE ASSERTS "
        "FROM (SELECT FROM Episode WHERE content = ? AND session = ?) "
        "TO (SELECT FROM Fact WHERE predicate = ? AND value = ? "
        "    AND valid_to IS NULL)",
        source, session, predicate, value)

Now “where does the user work?” has one right answer, and “where did the user work in April?” is still answerable. Nothing was destroyed.

Recall: Similarity, Then Structure

Retrieval runs in two layers. Semantic recall finds episodes that resemble the question; structural recall pulls the facts that are currently true.

def recall(db, question, k=5):
    q = embed(question)

    # 1. Episodes that resemble the question, plus what they mention
    episodes = db.query("sql",
        "SELECT content, ts, distance, out('MENTIONS').name AS entities "
        "FROM ( SELECT expand(vector.neighbors('Episode[embedding]', ?, ?)) )",
        q, k)

    # 2. Facts that are currently true about those entities
    facts = db.query("sql",
        "SELECT predicate, value, out('ABOUT').name AS subject "
        "FROM Fact WHERE valid_to IS NULL "
        "AND out('ABOUT').name IN ?",
        [e for row in episodes for e in (row.get("entities") or [])])

    return episodes, facts

The second query is the one that makes the agent reliable. It returns only facts whose valid_to is null, so superseded beliefs cannot leak back into the prompt no matter how semantically similar the old episode was.

Wiring It Into a Framework

If you already drive your agent through a framework, you do not need to hand-roll the retrieval layer. The shape of that layer, graph traversal plus vector search in one store, is what the Graph RAG page covers.

LangChain. The official langchain-arcadedb package provides ArcadeDBGraph, which implements LangChain’s GraphStore protocol and connects over ArcadeDB’s Bolt protocol.

from langchain_arcadedb import ArcadeDBGraph

graph = ArcadeDBGraph(
    url="bolt://localhost:7687",
    username="root",
    password="playwithdata",
    database="agent-memory",
)
print(graph.get_schema)

LlamaIndex. llama-index-graph-stores-arcadedb implements the LlamaIndex PropertyGraphStore interface.

MCP. ArcadeDB ships an MCP server, so an LLM can query the memory graph directly as a tool. See connecting your LLM to your database with MCP.

Note that the LangChain path needs a running server with the Bolt plugin enabled, whereas the embedded path above needs no server at all. Both talk to the same storage format.

Why This Runs Well

Recall sits in the agent’s request path, so traversal speed is not an academic concern. On the LDBC Graphalytics suite, run on identical hardware against seven other graph engines, ArcadeDB completes weakly connected components in 0.08s and PageRank in 0.10s, winning 5 of the 6 standard algorithms. On the LSQB pattern-matching benchmark, Q6, a two-hop traversal counting 1.67 billion rows, finishes in 110ms. Full methodology and the reproducible harness are on the benchmarks page.

Embedded mode removes the network entirely, which for a single-process agent is usually the largest remaining latency term.

Honest Comparison

ArcadeDB is not the only option that stores graph and vectors together. Memgraph and FalkorDB both index embeddings in the same store as the graph and both target agent memory explicitly, and either is a reasonable choice.

The differences worth weighing are licensing and breadth. Memgraph Community is BSL 1.1 and FalkorDB is SSPLv1, both source-available rather than OSI open source; ArcadeDB is Apache 2.0. ArcadeDB also stores documents and time series alongside the graph, and runs embedded in your Python or JVM process rather than only as a server. The full side-by-side is in open source knowledge graph and GraphRAG databases compared.

Frequently Asked Questions

What is memory for an LLM agent?

Agent memory is the state an agent keeps between turns and between sessions. It usually splits into episodic memory (what happened, turn by turn), semantic memory (durable facts learned about entities), and working memory (the current context window). Only the first two need a database.

Why is a vector store alone not enough for agent memory?

A vector store retrieves passages that resemble the query, but it cannot express that a fact was superseded, that two names refer to one person, or that a preference belongs to a project rather than a user. Those are relationships and validity intervals, which is what a graph stores.

How do you stop an agent from recalling outdated facts?

Do not overwrite facts; invalidate them. Give each fact edge a valid_from and valid_to timestamp, and when a new value arrives, close the old edge instead of deleting it. Retrieval then filters to edges where valid_to is null, and the history stays auditable.

Can ArcadeDB store agent memory and the embeddings together?

Yes. Embeddings live in a property on the same records that carry the graph, indexed with HNSW. A single transaction writes an episode, its vector, and its relationships, so semantic recall and relationship traversal run against one consistent copy of the data.

Does ArcadeDB work with LangChain for agent memory?

Yes. The official langchain-arcadedb package provides ArcadeDBGraph, which implements the LangChain GraphStore protocol and connects over ArcadeDB’s Bolt protocol. There is also a LlamaIndex PropertyGraphStore integration, and an MCP server that lets an LLM query the database directly.

Can agent memory run without a database server?

Yes. The arcadedb-embedded Python package runs the full engine inside your agent process, with a bundled Java runtime. For a single-process agent or a local assistant, that removes the server, the network hop, and the deployment entirely while keeping graph and vector recall.

Getting Started

pip install arcadedb-embedded

That is the whole install: the wheel bundles a Java runtime, so there is no JDK to set up. From there, the schema above is a working starting point you can adapt.

For the retrieval patterns behind this, see GraphRAG on ArcadeDB. For entity extraction and knowledge graph construction, see knowledge graphs. ArcadeDB is Apache 2.0 and free in production, with no node limits and no enterprise edition.

The short version: three of the eight index vectors in the same store as the graph, and can therefore serve GraphRAG on their own: ArcadeDB, Memgraph, and FalkorDB. They differ mainly on licence. ArcadeDB is Apache 2.0, Memgraph Community is BSL 1.1, FalkorDB is SSPLv1. Our own take on serving retrieval from one store is on the Graph RAG and knowledge graphs pages. Only ArcadeDB is OSI open source, and only ArcadeDB also stores documents and time series and runs embedded.

A word on where this is published. This is the ArcadeDB blog, we build ArcadeDB, and we think it is the best fit for most knowledge graph projects in 2026. You should discount our opinion accordingly. What we can do is be precise about the things that are checkable: which licence each project uses, when it last shipped a release, and what it does not do. Every status claim in this article was verified against the project’s own repository on 30 July 2026, and we say plainly where an alternative is the better choice.

Two of the eight are not really live options any more, and we say so rather than padding the list.

What Makes a Knowledge Graph Database?

A knowledge graph is not just a graph. It is a graph where the nodes represent real entities (people, documents, products, concepts), the edges carry typed meaning (authored-by, cites, depends-on), and the whole thing is used to answer questions that require following those relationships rather than filtering a table.

That imposes requirements beyond “can store nodes and edges”:

• Multi-hop traversal at usable speed. The value of a knowledge graph is in the questions that cross three or four relationships. If those queries take minutes, nobody asks them.
• Semantic retrieval. Users do not know your terminology. Someone searching for “how to handle errors in the payment service” needs to find a document titled “Exception Management in Billing Module”. That requires vector embeddings, not keyword matching.
• Exact retrieval too. Sometimes the query is a specific error code or clause number, where semantic similarity is exactly wrong and you need literal full-text matching.
• A licence you can actually build on. If you plan to embed the database in a product you distribute, a copyleft licence is a business decision, not a footnote.
• Someone still maintaining it. A knowledge graph is long-lived infrastructure. Adopting an unmaintained engine means you have adopted its unfixed bugs permanently.

That last criterion eliminates more candidates than people expect.

1. ArcadeDB

Licence: Apache 2.0 · Latest release: 26.7.3 (July 2026) · Status: actively developed

ArcadeDB is a multi-model database that stores graph, document, key-value, full-text search, vector, and time-series data in one engine, under a single ACID transaction boundary.

Why It Stands Out

For knowledge graph work specifically, the argument is that a knowledge graph needs three retrieval modes and most stacks make you run three databases to get them.

Graph, vectors, and full-text in one query. A realistic knowledge graph query does several things at once: find the entities semantically related to a question, filter to those matching an exact identifier, then traverse out to everything connected. On ArcadeDB that is one statement against one copy of the data. On most alternatives it is a graph query, a separate vector search, and an application layer merging the results, with the consistency between the two stores becoming your problem.

Native vector search. ArcadeDB indexes embeddings with JVector, using DiskANN and HNSW with SIMD acceleration, over the same records that hold the graph. There is no plugin to install and no external service to keep in sync.

Five query languages. SQL, OpenCypher 25, Apache TinkerPop Gremlin, GraphQL, and the MongoDB query language all run against the same data. The Cypher engine is native rather than a translation layer and passes 97.8% of the official TCK, which matters if you are moving existing queries across.

Apache 2.0, with no edition split. Clustering with Raft consensus, replication, embedded mode, and vector search are all in the free build. There is no Enterprise edition holding back the features you need in production, and no node or core limit.

Embedded or server. ArcadeDB runs inside your JVM, or in Python in-process via pip install arcadedb-embedded with a bundled JRE. For a knowledge graph feeding a local RAG pipeline, that removes the server entirely.

Where It’s Not the Best Fit

Honesty requires a real list here, not a token one.

It is the smallest community of the six. ArcadeDB has roughly 1,055 GitHub stars against Neo4j’s enormous ecosystem, Cayley’s 15,000, and JanusGraph’s 5,800. That translates into fewer Stack Overflow answers, fewer blog posts when you hit an edge case, and fewer engineers who already know it. If hiring people who have used your database before is a hard requirement, this is a genuine argument against us.

It is not a triplestore. If your knowledge graph is RDF, your data is in Turtle or N-Triples, and your team writes SPARQL, ArcadeDB is the wrong shape. It is a property graph engine. Use a dedicated RDF store.

It does not shard a single graph across machines. ArcadeDB replicates for availability rather than partitioning one graph across a cluster. If your graph genuinely exceeds what one machine can hold, JanusGraph over Cassandra is the more honest answer.

It runs on the JVM. The bundled-JRE Python package hides this well, but the engine is Java. If your operational policy excludes the JVM, that is decisive.

2. Neo4j Community Edition

Licence: GPLv3 · Status: actively developed

Neo4j is the reference point for property graphs, and Community Edition is a genuinely capable database. It is also the option most often adopted without reading the licence.

The Good

The ecosystem is unmatched. More documentation, more tutorials, more courses, more consultants, and more people who already know Cypher than every other option on this list combined. For a team learning graph modelling from scratch, that is worth a great deal.

Cypher is excellent. Neo4j designed the language that the rest of the industry now implements. It is genuinely pleasant for pattern matching.

Full ACID and a mature engine. Community Edition is not a crippled demo. For single-instance workloads it is a solid production database.

The Problems

GPLv3 is a business decision. Community Edition is copyleft. If you distribute software that includes or links to it, the licence reaches your application. For internal deployments this is usually irrelevant; for anything you ship to customers it is often a blocker, and the escape hatch is a commercial Enterprise licence.

No clustering. Community Edition does not support clustering, so it is limited to single-instance deployments. High availability and read scaling are Enterprise features. For a knowledge graph that becomes load-bearing infrastructure, that ceiling arrives eventually.

Graph only. Neo4j stores graphs. Documents, time series, and the rest live in other systems, which for knowledge graph work usually means running a separate store for the source documents alongside the graph of extracted entities.

When to Choose It Anyway

If your team already knows Cypher, your deployment is internal and single-instance, and you value ecosystem depth over licence flexibility, Neo4j Community Edition is a reasonable and low-risk choice. Plenty of successful knowledge graphs run on it.

3. Memgraph

Licence: BSL 1.1 (Community) · Latest release: v3.12.0 (July 2026) · Status: actively developed

Memgraph is an in-memory, Cypher-compatible graph database written in C++, and it has aimed squarely at GraphRAG and agent memory. If you have asked an AI assistant about GraphRAG recently, there is a good chance it cited Memgraph.

The Good

Built for this workload. Memgraph ships text and vector indexes in the same store as the graph, so a retrieval pipeline can run graph traversal and similarity search as one database operation rather than two systems stitched together. This is the same architectural argument we make for ArcadeDB, and it is a fair one when they make it.

In-memory speed. Holding the working set in memory gives Memgraph excellent latency on traversals, which matters when retrieval sits in the request path of an agent loop.

Cypher compatible. Existing Cypher and Neo4j-shaped tooling largely carries over.

The Problems

BSL is not open source. Memgraph Community is licensed under the Business Source License 1.1, which the Open Source Initiative does not recognise as an open-source licence. It restricts commercial use in ways a permissive licence does not, and Enterprise sits behind a separate proprietary licence. If your reason for avoiding Neo4j was licensing, read the BSL carefully before treating Memgraph as the escape.

In-memory is a cost model. RAM is the constraint. For a knowledge graph that is large and mostly cold, keeping it resident is a different budget from a disk-based engine.

Graph plus vectors, not multi-model. Documents and time series live elsewhere.

When to Choose It Anyway

If latency is your dominant constraint, your graph fits comfortably in memory, and BSL is acceptable to your legal team, Memgraph is genuinely strong at exactly this workload. It is the most direct competitor to ArcadeDB on GraphRAG and we would rather say so than pretend otherwise.

4. FalkorDB

Licence: SSPLv1 · Latest release: v4.20.1 (July 2026) · Status: actively developed

FalkorDB is the continuation of RedisGraph after Redis discontinued it, rebuilt around GraphBLAS sparse adjacency matrices and aimed explicitly at knowledge graphs for LLMs.

The Good

GraphBLAS is a genuinely good fit. Representing the graph as sparse matrices turns multi-hop traversal into linear algebra, and it makes FalkorDB fast on the pattern-matching workloads GraphRAG generates.

HNSW vector index in the same store. Like Memgraph, FalkorDB indexes embeddings alongside the graph, so hybrid retrieval does not require a second database.

Cypher, with a low-friction operational model. It runs as a Redis module, which is familiar territory for a lot of teams.

The Problems

SSPL is source-available, not open source. The Server Side Public License restricts how you may offer the software as a service and is not an OSI-approved open-source licence. For most self-hosted users this is not a practical constraint, but it is not the same freedom Apache 2.0 gives you, and it should not be described as open source.

Graph and vectors only. Same limitation as Memgraph: no document or time-series model.

Redis-module operational shape. Convenient if you already run Redis, an additional dependency if you do not.

When to Choose It Anyway

If you want fast GraphRAG retrieval, you already operate Redis, and SSPL is acceptable, FalkorDB is a well-built option with a clear focus on exactly this use case.

5. JanusGraph

Licence: Apache 2.0 · Latest release: 1.1.0 (November 2024) · Status: maintained, slow release cadence

JanusGraph is a distributed graph database under the Linux Foundation, and the direct descendant of Titan. It is the option built for graphs that genuinely do not fit on one machine.

The Good

Real horizontal scale. JanusGraph is a graph layer over a distributed storage backend, shipping support for Apache Cassandra, Apache HBase, and Oracle Berkeley DB Java Edition. If you already run Cassandra at scale, JanusGraph inherits that operational maturity and partitions a graph across it in a way most single-node engines cannot.

Genuinely open, genuinely neutral. Apache 2.0, under the Linux Foundation, with no vendor holding an Enterprise edition back. There is no commercial upsell waiting.

TinkerPop native. Gremlin is the query language, and JanusGraph is a first-class TinkerPop implementation, so the wider Gremlin tooling ecosystem works.

The Problems

You are operating at least two distributed systems. JanusGraph is not a complete database. Production means running and tuning Cassandra or HBase underneath it, plus usually Elasticsearch or Solr for indexing. The operational burden is substantially higher than any single-binary option here, and that is the dominant cost for most teams.

Slow release cadence. Version 1.0.0 arrived in October 2023 and 1.1.0 in November 2024. The repository is active, but a project shipping roughly one release a year is a different maintenance proposition from one shipping monthly.

Gremlin only, and no native vectors. There is no Cypher and no SQL. For semantic search you will pair it with a separate vector database, which for knowledge graph work means the multi-store architecture again.

When to Choose It Anyway

If your graph is genuinely too large for one machine and you already operate Cassandra or HBase, JanusGraph is the right answer and we would tell you so. That is a real scenario and no amount of single-node performance changes it.

6. TerminusDB

Licence: Apache 2.0 · Latest release: 12.0.6 (June 2026) · Status: actively developed

TerminusDB is a document graph database whose distinguishing idea is git-style version control for data: branching, merging, diffing, and time travel over the database itself.

The Good

Versioning is a first-class feature, not a pattern you implement. For a knowledge graph curated by humans, being able to branch the graph, make changes, review a diff, and merge is genuinely valuable and nothing else on this list offers it natively. Regulatory and scientific use cases where you must prove what the data said last quarter are a natural fit.

Apache 2.0 and actively shipping. Releases are current, the repository saw commits the week this was written, and the licence is permissive.

Document plus graph model. Data is modelled as documents with a schema, connected as a graph, which fits knowledge graph work better than a pure triplestore for most application developers.

The Problems

Smaller ecosystem than its age suggests. Roughly 3,370 GitHub stars and a modest contributor base. Documentation and community answers are thinner than Neo4j or JanusGraph.

No native vector search. TerminusDB does not index embeddings alongside the graph, so semantic retrieval means a separate vector store.

WOQL is a learning curve. The native query language is its own thing rather than Cypher, SQL, or Gremlin, so existing team knowledge does not transfer.

When to Choose It Anyway

If versioning and provenance are the primary requirement rather than a nice-to-have, TerminusDB is the strongest option here and the comparison is not close.

7. Cayley

Licence: Apache 2.0 · Latest tagged release: v0.7.7 (October 2019) · Status: effectively dormant

Cayley is a linked-data graph database written in Go, inspired by the graph infrastructure behind Google’s Knowledge Graph. It has 15,045 GitHub stars, which is more than anything else on this list, and it is the clearest illustration of why star counts are a poor proxy for project health.

The Good

The design is genuinely nice. A Go binary with pluggable backends, a clean HTTP API, and a small footprint. For a read-mostly linked-data store it is pleasant to work with.

Permissively licensed with no vendor. Apache 2.0, no commercial edition, no strings.

The Problems

No tagged release since October 2019. That is the single fact that matters. The repository is not archived and there is occasional commit activity, but a database that has not cut a release in nearly seven years is not something to build a knowledge graph on in 2026. Bug fixes, security patches, and dependency updates are not arriving on any schedule you can rely on.

No vector search, no modern AI integration. Cayley predates the entire embedding era and has no answer for semantic retrieval.

Query languages are its own. Gizmo, a JavaScript-based query API, alongside GraphQL and MQL variants.

Verdict

We would not start a new knowledge graph on Cayley in 2026, and we would say the same if it were our own project. Included here because its star count keeps it near the top of search results, and readers deserve to know that the number reflects 2015 enthusiasm rather than 2026 maintenance.

8. Kuzu

Licence: MIT · Latest release: v0.11.3 (October 2025) · Status: archived

Kuzu was an embedded analytical graph database with a columnar storage engine and a Cypher interface, and it was genuinely good at what it did.

What Happened

The GitHub repository was archived in October 2025 following the team’s acquisition by Apple. Development stopped. The code remains available under MIT, and community forks exist, but there is no funded maintainer and no release schedule.

Strengths, While It Lasted

Excellent analytical performance. Kuzu’s columnar engine was fast on multi-hop analytical queries, and it still appears in benchmark comparisons, including our own LDBC results, where it is marginally faster than ArcadeDB on LSQB Q2. We are not going to pretend otherwise.

Embedded and Python-first. It brought embedded graph workloads to Python properly, which is exactly the niche arcadedb-embedded now occupies.

Limitations

It is archived. Everything else is secondary. An archived database is not a foundation for new infrastructure, however good the engine was.

MIT means the code survives. If you already run Kuzu, you are not stranded, and forking is legally straightforward. But you now own a database engine, which is a larger commitment than most teams intend to make.

The Comparison at a Glance

Star counts and release data verified against each project’s GitHub repository on 30 July 2026.

Why Licensing Matters for Knowledge Graphs

Knowledge graphs have a licensing problem that other databases do not, because they tend to end up embedded in products rather than sitting behind a service boundary.

A knowledge graph that powers an internal search tool is a service you deploy, and GPLv3 is largely irrelevant. A knowledge graph that ships inside a desktop application, an on-premise product, or a customer-installed agent is distributed software, and a copyleft licence reaches your code. Teams frequently discover this after the architecture is settled.

Apache 2.0, used by ArcadeDB, JanusGraph, TerminusDB, and Cayley, permits embedding in proprietary software with no source obligation. MIT, used by Kuzu, is similarly permissive. GPLv3, used by Neo4j Community Edition, does not, and the commercial escape hatch is priced accordingly.

The second licensing question is what the free edition withholds. Neo4j reserves clustering and embedded mode for Enterprise. ArcadeDB, JanusGraph, and TerminusDB do not have a paid edition holding features back at all.

So Which One Should You Choose?

Choose ArcadeDB if you want graph traversal, vector search, and full-text retrieval in one engine under a permissive licence, and you would rather not operate three databases to build one knowledge graph. Accept that you are picking the smallest community here.

Choose Neo4j Community Edition if ecosystem depth matters more than licence flexibility, your deployment is internal and single-instance, and your team already writes Cypher.

Choose Memgraph if retrieval latency is the dominant constraint, your graph fits in memory, and your legal team is comfortable with BSL 1.1.

Choose FalkorDB if you want fast GraphRAG retrieval, already operate Redis, and SSPL is acceptable.

Choose JanusGraph if your graph genuinely does not fit on one machine and you already operate Cassandra or HBase. Do not choose it to avoid that operational burden, because it adds to it.

Choose TerminusDB if data versioning, branching, and provenance are core requirements rather than conveniences.

Do not start on Cayley in 2026, despite the star count, unless you are prepared to maintain it.

Do not start on Kuzu, because it is archived, unless you are deliberately adopting a fork and accepting ownership.

Key Takeaways

• Six of these eight are actively maintained. Cayley has not cut a release since 2019, and Kuzu was archived in October 2025.
• GitHub stars measure historical enthusiasm, not current health. Cayley has the most stars and the least maintenance.
• Licensing determines whether you can embed the database in a distributed product. Apache 2.0 and MIT permit it; GPLv3 constrains it.
• GraphRAG needs graph traversal and vector similarity together. Three of these eight do both in one store: ArcadeDB, Memgraph, and FalkorDB. The other five expect a separate vector database.
• The GraphRAG shortlist comes down to licence: ArcadeDB is Apache 2.0, Memgraph is BSL, FalkorDB is SSPL. Only ArcadeDB is OSI open source, and only ArcadeDB is multi-model and embeddable.
• ArcadeDB’s genuine weakness is community size: it has the fewest GitHub stars of the eight.

Frequently Asked Questions

What is the best open source knowledge graph database in 2026?

It depends on what you already run. ArcadeDB, Memgraph, and FalkorDB all index vectors alongside the graph and can serve GraphRAG alone; they differ on licence, with only ArcadeDB being OSI open source. JanusGraph is better at scale on Cassandra or HBase, and TerminusDB is better when versioning matters most.

Which open source database is best for GraphRAG?

GraphRAG needs graph traversal and vector similarity in the same query. ArcadeDB, Memgraph, and FalkorDB all index embeddings in the same store as the graph, so any of the three can serve GraphRAG without a separate vector database. ArcadeDB is the only one of the three under an OSI-approved open source licence.

Is Neo4j Community Edition suitable for a production knowledge graph?

It can be, with two caveats. Community Edition is GPLv3, which is a copyleft licence that affects how you can distribute software built on it, and it does not support clustering, so it is limited to single-instance deployments. Both are Enterprise Edition features.

Which open source knowledge graph databases are still actively maintained?

As of July 2026, ArcadeDB, Memgraph, FalkorDB, TerminusDB, JanusGraph, and Neo4j all ship releases. Kuzu was archived on GitHub in October 2025 after its team was acquired by Apple. Cayley’s repository is not archived but its last tagged release, v0.7.7, dates from October 2019.

Do I need a separate vector database for a knowledge graph?

Not necessarily. A knowledge graph that also serves semantic search needs both relationships and embeddings. ArcadeDB indexes vectors natively with JVector alongside the graph, so a single query can rank by similarity and traverse edges. Most alternatives require pairing the graph with a separate vector store.

What is the difference between a knowledge graph and an RDF triplestore?

A triplestore models data strictly as subject-predicate-object triples and typically queries with SPARQL. A property graph attaches arbitrary properties to nodes and edges and queries with Cypher, Gremlin, or SQL. Both can express a knowledge graph; property graphs are usually easier for application developers.

Does JanusGraph need Cassandra or HBase to run?

JanusGraph is a graph layer rather than a complete storage engine, so it runs on top of a separate backend. It ships support for Apache Cassandra, Apache HBase, and Oracle Berkeley DB Java Edition. Berkeley DB suits local development; Cassandra or HBase is expected in production.

Getting Started with ArcadeDB

If the single-engine argument is the one that lands, the fastest way to test it is to build a small knowledge graph on your own data and see whether one query really can do all three retrieval modes.

docker run --rm -p 2480:2480 -p 2424:2424 \
  -e JAVA_OPTS="-Darcadedb.server.rootPassword=playwithdata" \
  arcadedata/arcadedb:latest

Then open ArcadeDB Studio at http://localhost:2480 and start modelling. For the concepts behind entity extraction, semantic search, and temporal knowledge, see knowledge graphs on ArcadeDB. If you are building retrieval for an LLM on top of it, GraphRAG covers the hybrid retrieval patterns. If you are migrating an existing graph, the Neo4j migration guide covers Cypher and Bolt compatibility.

ArcadeDB is Apache 2.0, free in production, with no node limits and no Enterprise edition. Benchmark it against whatever you run today and keep whichever wins.

Upgrade if you can. It matters most if you expose the MCP server, run in server or multi-tenant mode, or store high-degree (super-node) graphs. There are no breaking changes and no schema migration in this release.

Major Highlights

Security Advisories

All three come from the same internal audit that produced the 26.7.2 fixes, covering MCP-transport and trigger surfaces that round did not reach.

• MCP command transport disabled all engine permission checks (GHSA-6x73-v3rc-f57c). The MCP transport never bound the authenticated principal onto the request thread’s DatabaseContext, so the engine permission gates (which are deliberate no-ops when no user is bound) silently passed for every MCP caller. A non-root, MCP-allowed reader could perform arbitrary writes, DDL, and schema or security mutation; the query + js sub-case could execute arbitrary in-JVM JavaScript. The principal is now bound at the single DB-resolution chokepoint and cleared on the pooled worker thread, so the engine per-user gates enforce for MCP exactly as they do for the HTTP, Bolt, PostgreSQL, and gRPC transports.
• MCP get_server_settings leaked the HA clusterToken in cleartext (GHSA-p9wc-4fhr-78wm). The MCP get_server_settings tool masked only settings whose key contained "password", so arcadedb.ha.clusterToken was returned raw. That token is the trust anchor for cluster-forwarded authentication, so leaking it enables full root impersonation. This is the MCP sibling of the 26.7.2 fix (GHSA-46hj-24h4-j8gf); the tool now redacts both value and default via GlobalConfiguration.isHidden(), matching GetServerHandler.
• JavaScript / Java triggers could escalate a schema admin to server-wide admin (GHSA-38pf-6hp2-pxww). A JAVASCRIPT trigger binds the real database object into a GraalVM context, so its script could call database.getSecurity().createUser(...) and escalate an UPDATE_SCHEMA (schema-admin) user to a server-wide admin; a JAVA trigger runs an arbitrary loaded class. Creating either host-code trigger type now requires UPDATE_SECURITY at the LocalSchema.createTrigger chokepoint, mirroring the DEFINE FUNCTION ... LANGUAGE js gate (GHSA-vwjc-v7x7-cm6g). Declarative SQL triggers keep UPDATE_SCHEMA, and schema reload of existing triggers is unaffected.

Major Fixes

Graph Engine

• Edge-append merge no longer reverts concurrent writes on multi-page edge chunks (#5302). The commutative edge-append merge (GRAPH_EDGE_APPEND_MERGE, introduced in 26.7.2) resolved a commit-time page conflict by re-deriving the conflicted page and replaying the transaction’s tracked appends. For an edge chunk stored as a multi-page record (a chunk that straddles a page boundary) this re-derivation was unsound: the rebase re-read the chunk through the transaction’s stale in-transaction page copy and committed it, silently reverting concurrently committed appends on the continuation page. The observable symptoms were zeroed chunk tails, shifted or aliased pairs, lost edges, and BufferUnderflowException on later traversals of the vertex.

  Only records living entirely in place on the conflicted page are now re-derived. Multi-page and indirected (placeholder) chunk records fall back to the standard full-transaction retry. Single-page chunks, which are the vast majority and include all super-node stripe chunks, keep the merge.

MCP Server

• get_schema now builds its schema through a dedicated buildSchema path.
• The MCP dispatcher handles a missing resource with a proper MCPResourceNotFoundException instead of a generic failure.

Getting Started with 26.7.3

Docker

docker pull arcadedata/arcadedb:26.7.3

Visit our Docker Hub repository for more information.

Maven

<dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-engine</artifactId>
    <version>26.7.3</version>
</dependency>

All artifacts are available on Maven Central.

Documentation

For details on features and usage, see the documentation.

Compatibility Note

This release contains no breaking changes and no schema migration. It maintains 100% compatibility with previous database formats, meaning no export/import is required when upgrading. As always, we recommend creating a database backup before upgrading.

Download ArcadeDB 26.7.3 now: GitHub Releases

Thanks to everyone in the community who reported issues, opened PRs, and helped shape this release.

Luca Garulli ArcadeDB Founder

ArcadeDB has spoken Bolt for a while, and the honest version of our claim was narrow: the official Neo4j drivers connect, and simple queries work. Useful, but not the same thing as compatibility. The gap between the two is where users get hurt. The driver connects on Monday; on Thursday someone reads a datetime back out of a query and gets a string.

ArcadeDB 26.7.2 closes that gap. It ships a shared conformance spec, all five official drivers under test, fixes for the protocol bugs that testing exposed, and a compatibility matrix that regenerates itself every night and is published where anyone can read it.

The audit

We started by auditing what we actually had (epic #4882). Some of it was reassuring. The full Bolt 3.0/4.0/4.4 message set was implemented, ROUTE included, along with a hand-written PackStream encoder, correct structure tags for Node, Relationship, and Path, TLS via bolt+s, and Neo4j-style structured error codes.

The rest was not:

• Bolt 5.x was never advertised. The server negotiated 3.0, 4.0, and 4.4. Modern 5.x drivers worked only by silently downgrading, which nobody had documented or tested as a deliberate stance.
• Temporal values went out as strings. Date, Time, LocalDateTime, DateTime and friends were serialized as ISO-8601 text instead of native Bolt structures. Duration and spatial Point had no handling anywhere. The driver dutifully handed your application a String.
• Neo.TransientError.* did not exist. Only a handful of ClientError and DatabaseError codes were defined, so the drivers’ managed-transaction retry logic could never fire the way it does against Neo4j.
• ROUTE was single-node only. It returned this node’s own address as writer, reader, and router, so neo4j:// routing against a real HA cluster was unproven.
• Three of the five official drivers had zero Bolt coverage. The Python and C# e2e suites tested the Postgres wire protocol and HTTP. There was no Go module at all.
• Java and JavaScript coverage was shallow. Connect, run a query, one regression test. No transactions, no error paths, no type round-trips.

A compatibility claim you cannot fail is not a compatibility claim. That list is why the epic existed.

The rules we set

Certify depth, not presence. “The driver connects” is not certification. Every driver runs the full feature matrix, and every unsupported cell becomes a documented limitation instead of a silent omission.

Only the real drivers. neo4j-java-driver, neo4j-driver, neo4j, Neo4j.Driver, neo4j-go-driver. No mocks, no bespoke socket clients. If the driver your application imports cannot do it, we do not get to claim it.

One spec, five idiomatic suites. We deliberately did not build a YAML-driven test runner in five languages. The conformance spec is a reference document. Each scenario is hand-written into that language’s native framework (JUnit, jest, pytest, xUnit, go test) and tagged with the scenario ID. The spec owns what gets tested; the code stays polyglot and readable.

“Not supported” is an acceptable answer, as long as it is written down. Byte-for-byte parity with Neo4j server behavior was never the goal. Knowing exactly where we differ was worth more.

The spec: 39 scenarios, 9 areas

The matrix is defined once, in bolt/conformance/spec.yaml, across nine areas taken verbatim from the epic’s feature table:

Each scenario carries a stable ID (TYPE-011, PROTO-002), a fixture, given/when/then steps, and a status. Every test in every language embeds its scenario ID in the test name, so checking coverage is a grep.

The drivers: 14 pinned versions

Testing against latest tells you about today and nothing about tomorrow. Every language is pinned to a band set, resolved to concrete versions in driver-versions.md:

The latest band deliberately tracks the newest release, so a driver-side release that breaks compatibility trips our nightly run within a day of shipping.

Two of these bands carry compromises. The C# floor is 5.26.2 instead of a 4.x line, because Neo4j.Driver made breaking API changes in 5.0 that the shared suite cannot compile against. JavaScript has no 4.x band for the same reason. The 4.4 wire protocol is still covered through the Java 4.4.20 legacy driver. Both compromises are written down in the file, with the reasoning, so nobody has to reverse-engineer why a column is missing.

What the tests broke

The first full run lit up red, which was more or less the point. Everything from the audit list is now fixed in 26.7.2:

• Native temporal structures. Date, Time, LocalTime, LocalDateTime, and DateTime are emitted as native PackStream structures.
• Duration and Point. Both round-trip as native Bolt structures in both directions, bound parameters included.
• Neo.TransientError.*. Retryable conflicts now map to transient error codes, so the drivers’ executeWrite retry loop works out of the box instead of failing your write on the first optimistic-lock conflict.
• HA-aware ROUTE. neo4j:// returns the real cluster topology instead of the local node three times.
• Bolt 5.x negotiation. No more silent downgrade.
• Populated write counters. ResultSummary counters reflect what actually happened.

One breaking change to plan for

The temporal fix changes behavior, and it is the one thing to read before you upgrade. Values that used to arrive as strings now arrive as typed objects:

// Before 26.7.2: this returned an ISO-8601 String
String when = record.get("created").asString();

// 26.7.2 and later: it is a real temporal value
ZonedDateTime when = record.get("created").asZonedDateTime();

This is what every Neo4j driver expects, and it is still a change, so the 26.7.2 release notes call it out explicitly.

The part that keeps it true

A test suite that runs when someone remembers to run it eventually stops being true. The pipeline matters more than any single bug on that list.

All five language suites gate every pull request. On top of that, a nightly workflow runs the full cross-product: every scenario, every driver, every pinned version. Each language’s JUnit-style report becomes a set of per-cell results, the cells merge into a single bolt-compat-matrix.json, and that JSON is cross-referenced against the expected cell set from driver-versions.md. A cell that should exist and does not is treated exactly like a cell that ran and failed. Silence does not pass.

Three things then happen without anyone touching them:

1. A regression issue opens itself. Any red cell auto-opens a bolt-compat-regression issue, which closes itself when the matrix goes green again.
2. The matrix is rendered and committed. A small renderer turns the nightly JSON plus the spec metadata into COMPATIBILITY.md. Rows are scenarios grouped by area, columns are language:version, and cells are pass, fail, known limitation, not applicable, or not reported. Non-passing cells link to their tracking issue. The page carries a “last verified” timestamp and a link to the CI run that produced it.
3. The badge updates. A shields.io endpoint in the README goes green only when every applicable cell passes.

The red nights get published the same way the green ones do. A matrix that could only ever come out green would not be worth publishing.

What is not green

Every applicable cell passes today. Two cells are not green, both deliberately:

• ERR-003 (unauthenticated request returns Neo.ClientError.Security.Forbidden) is marked not applicable. It cannot be triggered through any official driver’s public API, because every official driver completes HELLO/LOGON internally before it hands your code a session. Reaching it would take a bespoke raw-socket client, which our own rules exclude. The row stays in the matrix with the explanation attached.
• CONN-004 (neo4j:// routing reflecting a real multi-node topology) is skipped, because the nightly runs against a single node. The HA-aware ROUTE implementation shipped in 26.7.2; the multi-node nightly harness for it did not. The cell carries a footnote about the HA_SERVER_LIST configuration it depends on, and it stays visible until something actually covers it.

The Java 4.4.20 column is sparse on purpose. It runs the legacy-driver subset that proves 4.4 wire negotiation still works, not the full modern-API suite.

Try it

Point any official Neo4j driver at an ArcadeDB server. Nothing special is required, and the rest of what a move off Neo4j involves is on the Neo4j migration page. Here is the same query in all five certified drivers:

try (Driver driver = GraphDatabase.driver("bolt://localhost:7687",
         AuthTokens.basic("root", "playwithdata"));
     Session session = driver.session(SessionConfig.forDatabase("beer"))) {

  session.run("MATCH (b:Beer)-[:HasCategory]->(c:Category) "
            + "WHERE c.name = $cat RETURN b.name AS name LIMIT 5",
      Map.of("cat", "Irish Ale"))
      .forEachRemaining(r -> System.out.println(r.get("name").asString()));
}

import neo4j from 'neo4j-driver';

const driver = neo4j.driver('bolt://localhost:7687',
  neo4j.auth.basic('root', 'playwithdata'));
const session = driver.session({ database: 'beer' });

const result = await session.run(
  'MATCH (b:Beer)-[:HasCategory]->(c:Category) ' +
  'WHERE c.name = $cat RETURN b.name AS name LIMIT 5',
  { cat: 'Irish Ale' }
);
result.records.forEach(r => console.log(r.get('name')));

await session.close();
await driver.close();

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687",
                              auth=("root", "playwithdata"))

with driver.session(database="beer") as session:
    result = session.run(
        "MATCH (b:Beer)-[:HasCategory]->(c:Category) "
        "WHERE c.name = $cat RETURN b.name AS name LIMIT 5",
        cat="Irish Ale",
    )
    for record in result:
        print(record["name"])

await using var driver = GraphDatabase.Driver("bolt://localhost:7687",
    AuthTokens.Basic("root", "playwithdata"));
await using var session = driver.AsyncSession(o => o.WithDatabase("beer"));

var names = await session.ExecuteReadAsync(async tx => {
    var cursor = await tx.RunAsync(
        "MATCH (b:Beer)-[:HasCategory]->(c:Category) " +
        "WHERE c.name = $cat RETURN b.name AS name LIMIT 5",
        new { cat = "Irish Ale" });
    return await cursor.ToListAsync(r => r["name"].As<string>());
});

names.ForEach(Console.WriteLine);

ctx := context.Background()

driver, err := neo4j.NewDriverWithContext("bolt://localhost:7687",
    neo4j.BasicAuth("root", "playwithdata", ""))
if err != nil {
    log.Fatal(err)
}
defer driver.Close(ctx)

session := driver.NewSession(ctx, neo4j.SessionConfig{DatabaseName: "beer"})
defer session.Close(ctx)

result, err := session.Run(ctx,
    "MATCH (b:Beer)-[:HasCategory]->(c:Category) "+
        "WHERE c.name = $cat RETURN b.name AS name LIMIT 5",
    map[string]any{"cat": "Irish Ale"})
if err != nil {
    log.Fatal(err)
}

for result.Next(ctx) {
    fmt.Println(result.Record().Values[0])
}

Managed transactions, bookmarks, neo4j:// routing, and typed temporal and spatial values behave the way the driver documentation says they should. Where they do not, the matrix says so.

Why we bothered

A large part of the graph world evaluates a database by pointing an existing driver at it, running existing Cypher, and seeing what breaks. That deserves a real answer instead of a compatibility adjective.

It is the same instinct behind our Jepsen work: publish the harness, publish the results, publish the parts that do not pass. All of it is open:

• Epic #4882: Bolt Driver Compatibility Certification
• The live compatibility matrix
• The conformance spec and how it is consumed
• The advertised server identity and why it says Neo4j/5.26.0 compatible

Get ArcadeDB 26.7.2: GitHub Releases or docker pull arcadedata/arcadedb:26.7.2

Run a Bolt workload against ArcadeDB and hit a case the matrix does not cover? Open an issue. A scenario we never thought to write is the most useful bug report we can get.

Roberto Franchini Director R&D

Major Highlights

Deep Engine Audit

The heart of this release is a systematic audit of the storage and execution engine. These are the guarantees you rely on every commit, tightened across the board:

• Storage & recovery: WAL append is now the transaction’s point of no return, with pre-write validation. Torn 64KB page writes are repaired during recovery, and the page cache prevents both lost updates and unbounded growth.
• LSM index stability: Compaction no longer loses re-inserted keys or leaks orphaned pages, range scans are no longer truncated by tombstoned entries, and non-unique lookups no longer resurrect deleted records.
• Transaction safety: Double-indexed updates within a single transaction no longer corrupt indexes, dead-thread cleanup rolls back abandoned transactions properly, and virtual-thread compatibility is restored.
• Parallel query safety: A dedicated thread pool for bucket scans prevents deadlocks, each worker gets an isolated command context, and native iterators bound producer offers and close cleanly.

These are the fixes you feel under load and during the unhappy path, not in a benchmark.

Neo4j Bolt Driver Certification

ArcadeDB now achieves full compatibility certification with the Neo4j Bolt driver:

• Native temporal PackStream structures: date, time, datetime, and localdatetime.
• Native Path, Duration, and Point types.
• Retryable conflict mapping so the driver’s auto-retry works out of the box.
• HA-aware ROUTE responses and Bolt 5.x negotiation support.
• Populated write-result counters.

Security Hardening: 5 Critical Fixes

This release patches five critical vulnerabilities. Upgrading is strongly recommended for internet-facing and multi-tenant deployments:

• RCE via JavaScript triggers: java.lang.* classes are removed from trigger allow-lists, restricting to benign packages only.
• Arbitrary JavaScript execution: defining js functions now requires UPDATE_SECURITY with restricted polyglot access.
• Secret disclosure via API: server settings now redact all hidden configuration keys, including cluster tokens.
• Cross-database IDOR: authorization checks added to 14 HTTP handlers to prevent unauthorized database access.
• Read-only mutation of schema: missing UPDATE_SCHEMA guards added to schema and config mutators.

High Availability (Raft) Enhancements

• Durable Raft storage now defaults to true, preventing follower divergence.
• The leader auto-recovers wedged replication channels.
• A new TransactionCommittedRemotelyException (HTTP 409) prevents duplicate retries.
• Offline bootstrap leadership-transfer now commits a baseline.

Major Fixes

Query Engine: OpenCypher

• Dynamic property mutations (SET n[key] = value) are now applied.
• Inline relationship filters are enforced in MATCH, exists(), comprehensions, and shortest-path queries.
• FOREACH updates are visible to subsequent RETURN clauses.
• Pattern comprehension and correlated subquery corrections.
• Temporal normalization is applied in index scans.

Query Engine: SQL

• FROM is now usable as a property name in DDL and queries.
• ORDER BY on non-indexed properties returns correct results.
• TRAVERSE with MAXDEPTH corrected; BREADTH_FIRST now performs true breadth-first traversal.
• Map indexing and array serialization fixes.

Additional Features

• User-defined functions are now persisted and distributed across HA clusters.
• Configurable vector quantization for sparse vector indexes.
• Commutative append-merge removes retry storms on high-degree vertices.
• Extended Cypher write-counter surfacing over HTTP and gRPC.
• Point datatype and spatial index support.
• Python binding performance improvements.

Dependencies

Notable upgrades include Netty 4.2.16, Jackson 2.22.1, PostgreSQL JDBC 42.7.13, GraalVM 25.1.3, and Neo4j Java driver 6.2.0, plus the usual round of updates.

Breaking Changes

Two behavioral changes to note when upgrading:

1. Raft storage durability: arcadedb.ha.raftPersistStorage now defaults to true. Ensure the storage directory resides on durable media. Test clusters can opt out explicitly.
2. Bolt temporal types: temporal values are now transmitted as native PackStream structures instead of ISO-8601 strings. Clients must read native types (e.g., asZonedDateTime()) rather than strings.

Getting Started with 26.7.2

Docker

docker pull arcadedata/arcadedb:26.7.2

Visit our Docker Hub repository for more information.

Maven

<dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-engine</artifactId>
    <version>26.7.2</version>
</dependency>

All artifacts are available on Maven Central.

Documentation

For detailed information on features and usage, refer to our comprehensive documentation.

Compatibility Note

This release maintains 100% compatibility with previous database formats, meaning no export/import is required when upgrading. As always, we recommend creating a database backup before upgrading.

Download ArcadeDB 26.7.2 now: GitHub Releases

Thanks to everyone in the community who reported issues, opened PRs, and helped shape this release.

Luca Garulli ArcadeDB Founder

All of it is opt-in. Touch no configuration key and your server behaves exactly as it does today. For how the server is deployed in the first place, see the client-server page.

What was already there, and what wasn’t

Single-node observability was in decent shape: Micrometer metrics with an in-memory registry, an optional /prometheus endpoint, JVM and executor-pool binders, an engine Profiler that tracks cache hit ratio, pages, WAL, transaction counts, and MVCC conflicts, a manual query profiler, and an /api/v1/ready endpoint.

The gaps only show up once you put that server in a cluster. Query, command, and transaction latency lived in the manual profiler, which means you had to go looking for it; there were no always-on RED (Rate, Errors, Duration) timers and no percentile histograms. There were no spans at all, so a request that crossed the query engine, a transaction, and a Raft replication hop was three disconnected mysteries. Logs were text-only, with nothing tying a line back to the request that produced it. And there was a readiness endpoint but no liveness check, which is the one Kubernetes reaches for first.

Instrument once, get two signals

The part of this design I like most is the one that required the least new code. Micrometer’s Observation API lets you instrument a code path once and emit either a timer or a span from it, depending on what happens to be registered at runtime. ArcadeDB already shipped Micrometer, so the core server now wraps its hot paths (HTTP request handling, query and command execution, transaction commit, and Raft replication) in Observation calls and stops there.

With no tracer registered, an Observation is a metrics-only timer: what already happened, under a new name. Install the tracing plugin and those same call sites start producing spans as well. No second instrumentation pass, no parallel set of trace annotations drifting out of sync with the metric ones. If you have ever maintained a codebase where the metrics and the traces disagree about what a “query” is, you know why this matters.

Metrics: RED timers and OTLP export

Three always-on timers, with percentile histograms and SLO buckets, exposed through /prometheus and optionally through OTLP:

• arcadedb.http.requests, tagged by method, path template, status, and database. The path template is deliberate: tagging by raw URI is how you blow up your cardinality budget and get a call from whoever pays the metrics bill.
• arcadedb.query.duration, tagged by language, database, and query type.
• arcadedb.tx.duration, tagged by database and outcome (commit or rollback).

A new EngineMetricsBinder, modeled on the existing PoolMetrics, pulls the engine Profiler’s cache hit ratio, page and WAL statistics, MVCC conflict counts, and the database-level and sparse-vector numbers into Micrometer gauges tagged by database. Set arcadedb.serverMetrics.otlp.enabled=true and the same series push to an OTLP collector. The Prometheus scrape path is not touched.

Tracing, in a module you can leave on the shelf

Tracing lives in a separate, optional tracing module, packaged the same way the metrics module already is: its own Maven module, provided scope on the server, loaded through the ServerPlugin SPI. The OpenTelemetry SDK, micrometer-tracing-bridge-otel, and the OTLP exporter stay inside it. The core server’s compile classpath never sees them, which was a hard requirement: nobody should inherit the OTel dependency tree because they wanted a graph database.

Set arcadedb.serverMetrics.tracing.enabled=true and the plugin registers a bridged tracer into Micrometer’s global ObservationRegistry. The Observations described above start producing spans, nested from HTTP down through query execution and transaction commit. Inbound requests continue an upstream trace through the W3C traceparent header, and outbound Raft RPCs propagate context, so a write is traceable from leader to follower.

Leave the jar off the classpath or the flag unset and it is a genuine no-op. No span overhead, no registry, nothing.

Structured logging and correlation IDs

A timer tells you the p99 moved. A span tells you which hop ate the time. Neither tells you about the IOException that got swallowed and retried, and that is usually the thing you actually needed. So the logs have to join the same conversation.

At the start of each request, ArcadeDB populates a diagnostic context with the active trace and span IDs, plus a generated request ID so correlation still works when tracing is off. The context is scoped per request and cleared in a finally block, because the server hands threads back to a worker pool and a leaked MDC entry means the next request inherits someone else’s trace ID. That bug is miserable to find. The finally is not decorative.

An opt-in JsonLogFormatter (arcadedb.server.logFormat=json) writes one JSON object per line: timestamp, level, logger, thread, message, trace ID, span ID, database, request ID, exception. It is built on ArcadeDB’s existing JSONObject, so it adds no JSON dependency. If you want correlation without moving to JSON, arcadedb.server.logIncludeTrace=true appends a [traceId=...] tag to the text format instead.

Health probes for Kubernetes

This is the smallest change in the whole set and probably the one most people will use: GET /api/v1/health. It is deliberately cheap. No database I/O, no auth, returns 200 as long as the process and the HTTP layer are up.

Cheapness is the entire point. Liveness must not depend on database readiness. Wire a readiness-style check into livenessProbe and Kubernetes will helpfully kill a node that is still replaying its WAL, then kill the replacement for the same reason, and you will spend an afternoon reading kubelet events before you work out that your health check is the outage.

/api/v1/ready is unchanged by default. It gains one optional behavior: with arcadedb.server.readinessRequiresHA=true and HA active, readiness reports false until the node has joined the Raft group and caught up. That gives clustered deployments a readinessProbe that means something.

livenessProbe:
  httpGet:
    path: /api/v1/health
    port: 2480
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /api/v1/ready
    port: 2480
  initialDelaySeconds: 5
  periodSeconds: 5

Configuration reference

Every new key defaults to off, or to what the server does today:

On not breaking anything

The whole design was built against one constraint: with no new configuration, an upgraded deployment behaves exactly as it did before. Existing endpoints and response shapes (/prometheus, /api/v1/server, /api/v1/ready) were added to, never modified. No configuration key was renamed. No new mandatory dependency lands on the core server, which is why the OpenTelemetry SDK sits behind the SPI in its own module rather than in the server pom.xml where it would have been considerably easier to put it.

Upgrade whenever you like, then turn things on one flag at a time.

Pairing it with Grafana

If you already run the ArcadeDB Grafana plugin for BI dashboards over SQL, Cypher, and Gremlin, the OTLP metrics and traces drop into the same stack. Point an OpenTelemetry Collector at the server, fan out to Prometheus and Tempo (or whatever your vendor of the month is), and you can go from a p99 spike on a dashboard to the trace behind it to the log line that explains it, without leaving the cluster.

Major Highlights

Raft & High Availability Hardening

The headline of this release is resilience. A cluster should survive a bad entry, a network blip, or a diverged replica without operator intervention:

• A failed apply on one database no longer halts the entire node. The affected database is put into per-database quarantine while every other database on the node keeps serving traffic.
• Diverged followers can now self-recover back to the leader’s state instead of getting stuck.
• Snapshot integrity is strengthened with fsync on write and manifest verification, so a follower never installs a truncated or corrupt snapshot.
• Membership changes are applied as atomic deltas under quorum protection, closing the classic split-brain and lost-quorum windows.
• Silent write loss on replication timeouts has been eliminated: a write that cannot be safely replicated is reported, not dropped.
• TRUNCATE TYPE and TRUNCATE BUCKET are now HA-safe, follower index correlation is fixed by stable peer-id, and a stalled replica stuck at matchIndex=-1 now auto-recovers.

These are the fixes you feel in production during the unhappy path, not in a benchmark.

OpenTelemetry Distributed Tracing & Structured Logging

Observability is now first-class. A new OpenTelemetry module provides end-to-end distributed tracing with optional OTLP export, so you can follow a request across the wire protocols, the query engine, and the storage layer in your existing tracing backend. Alongside it:

• Structured JSON logging with per-request correlation IDs, so a single request is trivial to reconstruct across logs and traces.
• Enhanced metrics with RED timers (Rate, Errors, Duration) and engine gauges.

Native BM25 Full-Text Scoring

Full-text search now ships a native BM25 scoring implementation with field boosts and caret (^) boost syntax, so relevance ranking is tunable per field. EXPLAIN and PROFILE now cover search operations too, making it easy to see how a full-text query is planned and executed.

ISO GQL Standards Alignment

ArcadeDB continues moving toward the ISO GQL graph query standard:

• Session management statements: SESSION SET / SESSION RESET / SESSION CLOSE.
• Transaction control statements: START TRANSACTION / COMMIT / ROLLBACK.
• Strict numeric types for standards-compliant arithmetic and comparisons.

Security Hardening

Another broad security sweep tightens the defaults for multi-tenant and internet-facing deployments:

• Polyglot scripting now requires administrative privileges.
• Centralized gRPC authorization enforcement across all endpoints.
• Additional path-traversal protection hardening.
• DoS bounding on gRPC result materialization.
• Cluster-management endpoints are now restricted to root access.

Major Fixes

Vector Engine

• New import/interop formats: MATLAB, MATLAB_COLUMN, JULIA, and NUMPY.
• New helper functions: asVector(), asSparse(), and vectorDequantizeBinary.
• Improved RRF (Reciprocal Rank Fusion) array input handling.

MongoDB Protocol

• Added update, delete, and createIndexes commands.
• SASL PLAIN authentication support.
• Improved find command data handling.

Kubernetes Operations

• Health probe endpoints for liveness, readiness, and startup.
• Auto-acquire capability for databases the node has not seen yet.
• StatefulSet scale-up support beyond a static peer list.

SQL & Queries

• Map/collection key removal now persists correctly in UPDATE.
• Improved index selection for composite-key queries.
• Three-valued logic for NULL operands in IN / NOT IN.
• Correct mixed-type numeric handling in GROUP BY and aggregation functions.

Storage & Recovery

• Schema recovery from the backup file when the primary schema is corrupted.
• Corrupt hash-index detection and recovery.
• Time-series negative-timestamp alignment fixes.
• Page I/O locking improvements.

Wire Protocols

• gRPC: InsertStream now terminates correctly after a commit failure.
• DATETIME precision is preserved across microsecond/nanosecond formats.
• OpenCypher now tolerates dangling edges.
• Improved client-side nested type hydration.

Dependencies

Notable upgrades include Netty 4.2.15, Lucene 10.5.0, OpenTelemetry BOM 1.63.0, Jackson Databind 2.22.0, and JVector 4.0.0-rc.8, plus the usual round of Studio frontend, e2e harness, and CI updates.

Getting Started with 26.7.1

Docker

docker pull arcadedata/arcadedb:26.7.1

Visit our Docker Hub repository for more information.

Maven

<dependency>
    <groupId>com.arcadedb</groupId>
    <artifactId>arcadedb-engine</artifactId>
    <version>26.7.1</version>
</dependency>

All artifacts are available on Maven Central.

Documentation

For detailed information on features and usage, refer to our comprehensive documentation.

Compatibility Note

This release maintains 100% compatibility with previous database formats, meaning no export/import is required when upgrading. As always, we recommend creating a database backup before upgrading.

Download ArcadeDB 26.7.1 now: GitHub Releases

Thanks to everyone in the community who reported issues, opened PRs, and helped shape this release.

Luca Garulli ArcadeDB Founder