The fraud is not in any of the five records. It is that account A’s phone number is account B’s, account B’s device fingerprint is account C’s, account C’s shipping address is account D’s, account D’s email is account E’s, and E is the beneficiary on a transfer from A. In a table that is five unremarkable rows. In a graph it is a closed loop you can see at a glance.

Fraud lives in the connections, which is why fraud detection is one of the few workloads where a graph database is the better tool on the merits, not because graphs are in fashion.

The shape of the problem

Most of what a fraud team chases falls into three schemes, and each one is a pattern in the edges.

Fraud rings. A set of accounts linked through shared attributes or circular money movement. The money leaves and comes back. No single account looks wrong.

Synthetic identities. An identity assembled from real and fabricated details, built up over months of legitimate behavior before the bust-out. The giveaway is rarely a bad record. It is a cluster of records that are suspiciously similar to each other without being identical.

Layering and smurfing. Money broken into small amounts and moved through intermediaries so that the path from origin to destination is obscured. Each hop is a legitimate-looking transfer, and the scheme only shows when you look at the whole path.

Every one of those is a question about relationships at a depth you do not know in advance, and the depth is what makes it hard. If you knew the ring was exactly three accounts, you could write the join. You do not, so you cannot.

Modeling it

Keep the model boring. Accounts, devices, and identifiers are vertices; transfers and usage are edges.

CREATE VERTEX TYPE Account;
CREATE VERTEX TYPE Device;
CREATE VERTEX TYPE Identifier;   -- phone, email, address, tax id

CREATE EDGE TYPE TRANSFERRED;    -- Account -> Account, with amount and timestamp
CREATE EDGE TYPE USED;           -- Account -> Device
CREATE EDGE TYPE CLAIMS;         -- Account -> Identifier

The one modeling decision that matters: make shared attributes into vertices, not properties. If a phone number is a property on Account, then “find every account sharing a phone number” is a self-join over a string column. If it is an Identifier vertex that accounts point at, it is a two-hop traversal, and the shared identifier is a first-class thing you can attach a confidence score or a review status to.

Finding the ring

A ring is a path that returns to where it began. That is one query, and the depth is a parameter rather than a rewrite. Every query in this section comes in both Cypher and ArcadeDB SQL; use the tabs to switch, and use whichever your team already reads. Both run against the same data in the same engine.

MATCH path = (a:Account)-[:TRANSFERRED*2..5]->(a)
WHERE a.id = $accountId
RETURN path

MATCH {type: Account, as: a, where: (id = :accountId)}
      .out('TRANSFERRED'){while: ($depth < 5),
                          where: ($depth >= 2 AND @rid = $matched.a.@rid),
                          pathAlias: ring}
RETURN ring.id AS accounts

*2..5 in Cypher, and the $depth bounds in SQL, mean: follow TRANSFERRED edges between two and five hops, and only return paths that arrive back at the account they started from. Ask for six hops instead and you change one number. In a relational database each extra hop is another self-join, so a deeper ring means a different query.

The ring from the opening closes over a phone, a device, an address, an email and one transfer. In Cypher that is the same query with more edge types and no direction, since a shared identifier is one hop out and one hop back:

MATCH path = (a:Account)-[:TRANSFERRED|CLAIMS|USED*2..10]-(a)
WHERE a.id = $accountId
RETURN [n IN nodes(path) WHERE n:Account | n.id] AS accounts

SELECT @in.id AS beneficiary,
       shortestPath(@in, @out, 'BOTH', ['CLAIMS', 'USED'], {maxDepth: 10})
         [@type = 'Account'].id AS ring
FROM TRANSFERRED
WHERE @out.id = :accountId

Each shared identifier costs two hops, so the five-account ring above is nine edges long, and the bound is set with that in mind. The SQL version comes at it from the transfer: for each payment the account made, it looks for a path back from the beneficiary over shared identifiers and devices. An empty ring means the two ends are not otherwise connected.

To rank an account’s neighbors by how much they share with it, count the identifiers per neighbor:

MATCH (a:Account)-[:CLAIMS]->(i:Identifier)<-[:CLAIMS]-(b:Account)
WHERE a.id = $accountId AND a <> b
RETURN b.id AS account, count(i) AS sharedCount, collect(i.type) AS shared
ORDER BY sharedCount DESC

SELECT id AS account, count(*) AS sharedCount
FROM (SELECT expand(out('CLAIMS').in('CLAIMS')) FROM Account WHERE id = :accountId)
WHERE id <> :accountId
GROUP BY id
ORDER BY sharedCount DESC

Two accounts sharing one identifier is weak evidence. Two accounts sharing four is not. The count is the signal, and grouping it out of the traversal costs nothing.

The ring alone is not enough

Graph database marketing tends to skip this part, and it is why a single ring query is not a fraud system.

A ring is not proof. Five accounts sharing an address might be a family, roommates, or a small business. Five accounts sharing a device might be a library. The traversal finds the pattern; it does not tell you the pattern is fraud. Run it alone and you will generate false positives at a rate your review team will hate you for.

Confidence comes from combining the structural signal with signals of a different kind: text similarity, behavior, and timing. ArcadeDB keeps each of those in the same database as the graph.

Fuzzy identity matching, for synthetics

Synthetic identities are near-misses by construction. 123 Main St Apt 4 and 123 Main Street #4. Jonathon and Johnathon. Exact matching finds none of it.

A full-text index, which ArcadeDB scores with BM25, ranks the near-matches. The index is created once, in SQL:

CREATE PROPERTY Identifier.value STRING;
CREATE INDEX ON Identifier (value) FULL_TEXT;

Then query it from either language:

CALL db.index.fulltext.queryNodes('Identifier[value]', '"123 Main" Apt~')
YIELD node, score
RETURN node.value AS value, node.type AS type, score
ORDER BY score DESC

SELECT value, type, $score AS score
FROM Identifier
WHERE SEARCH_INDEX('Identifier[value]', '"123 Main" Apt~') = true
ORDER BY score DESC

One near-match proves nothing on its own. A cluster of applications sharing near-miss identifiers, all filed within a few days of each other, is a pattern exact matching cannot see at all.

Behavioral distance, for bust-outs

An account that has behaved normally for eight months and then changes character is the classic bust-out. If you already embed account behavior as a vector, and many teams do, the change shows up as distance: recently active accounts whose behavior now sits close to a known fraud profile.

CREATE INDEX ON Account (behavior) LSM_VECTOR METADATA {dimensions: 128, similarity: 'COSINE'};

CALL db.index.vector.queryNodes('Account[behavior]', 20, $knownFraudVector)
YIELD node, score
WHERE node.lastActivity > $since
RETURN node.id AS id, score
ORDER BY score DESC

SELECT id, distance
FROM (SELECT expand(vectorNeighbors('Account[behavior]', :knownFraudVector, 20)))
WHERE lastActivity > :since
ORDER BY distance

Cypher reports a similarity score, where higher is closer. SQL reports a distance, where lower is closer. Both rank the same neighbors.

This signal is independent of the graph one. An account can be structurally isolated and behaviorally anomalous, or structurally suspicious and behaviorally boring. The accounts that are both are the ones to look at first.

Timing, for velocity

Fraud has a tempo. Ten transfers in a minute, or a burst of account creations from one subnet, is a question of bucketing events by time:

MATCH (a:Account)-[t:TRANSFERRED]->()
WHERE t.ts > datetime($since)
WITH a.id AS account_id,
     datetime.truncate('minute', t.ts) AS minute,
     count(t) AS transfers,
     sum(t.amount) AS total
WHERE transfers > 10
RETURN minute, account_id, transfers, total
ORDER BY total DESC

SELECT FROM (
  SELECT ts.timeBucket('1m', ts) AS minute,
         account_id,
         count(*) AS transfers,
         sum(amount) AS total
  FROM TransferEvent
  WHERE ts > :since
  GROUP BY minute, account_id
)
WHERE transfers > 10
ORDER BY total DESC

The two versions read different data. Cypher works on the graph, so it buckets the timestamps already on the TRANSFERRED edges. SQL reads TransferEvent, a time-series type, where the storage engine can answer a bucketed aggregation in one pass. That is the better home for a high-volume event stream, and Cypher does not query time-series types.

Why one database rather than four

Every signal above is weak on its own and meaningful in combination, and that has consequences for where the data lives.

If the graph lives in one system, the embeddings in a vector store, the identifiers in a search cluster, and the events in a time-series database, then combining them means four queries, four network round trips, a join written in application code, and four copies of the truth that drift at four different rates. Worse, the drift is invisible: nothing errors when your vector store is nine minutes behind your graph. You just score an account against a behavior profile that is no longer current.

With all four models in one engine, the join happens in the query and every signal reads the same committed data. That is a narrower claim than “one database for everything”. It applies here because fraud scoring combines these signals on every query, so keeping them apart costs you on every query too.

Where a traversal is the wrong tool

A graph is not the answer to everything, and two limits are worth knowing before you start.

Unbounded traversals will hurt you. [:TRANSFERRED*] with no upper bound on a dense graph can walk a very large portion of it. Every query above bounds the depth deliberately. Bound yours too, and exclude hub vertices by hand. A bank’s own settlement account touches everything; the engine will not work that out for you.

Whole-graph analytics is a different workload. Community detection or PageRank across the entire account graph is not a transactional traversal, and running it as one will disappoint you. That is what the Graph OLAP engine is for. It reads the same data as the transactional engine, so there is no export step between finding a community offline and querying it online.

Getting started

The schema above is six statements and the Cypher ring query is three lines. If you want the longer version, with the multi-model investigation flow and the FAQ, it is on the fraud detection page; the Academy covers the Cypher and SQL used here in more depth.

The FTC recorded $12.5 billion in consumer fraud losses in 2024, a 25% increase year over year, and the FBI’s Internet Crime Complaint Center put its own figure at $16.6 billion for the same period. A lot of that money moved through accounts that looked fine one row at a time.

At a Glance

Upgrading is recommended for every deployment, and in particular for every HA cluster and every time series workload. Behavior changes are collected in the upgrade checklist below.

New Features

Server and Operations

• Query admission gate (#9518). A FIFO queue in front of HTTP, Postgres, Bolt, Redis, MongoDB, gRPC and MCP: when the server is busy, requests wait and start in arrival order instead of all starting at once and exhausting the heap. It is on by default (arcadedb.queryMaxConcurrent, 2 x cores and at least 4, 0 disables it), bounded by arcadedb.queryQueueTimeout and arcadedb.queryQueueMaxSize, and heap-aware through arcadedb.queryAdmissionHeapWatermark. A refused request is retryable on every protocol (HTTP 503, Postgres 40001, Redis TRYAGAIN).
• List and terminate running queries (#9680, #9689). list queries [database <db>] [tag <t>], terminate query <id>, terminate queries tag <t>, list transactions and terminate transaction <sessionId> over POST /api/v1/server, with an X-ArcadeDB-Query-Tag header to find your own statements and an acknowledgement that says whether the statement stopped. Bolt, gRPC (streaming loads included), MCP, the Postgres wire and /ws insert sessions register their work too, and every entry names its client (#9774, #9838, #9875, #9962).
• Statement and plan cache by query shape (#8307). SQL and openCypher texts that differ only in their literals are parsed and planned once. On a unique-index point lookup, Cypher drops from 42 to 6.1 microseconds per query and SQL from 21.5 to 6.6; a query that already uses parameters costs what it did.
• Docker images run on Java 25 (eclipse-temurin:25-alpine), so compact object headers are finally enabled in the image (#9602). The native image now ships Raft HA, metrics and tracing (#9407), runs the e2e battery in CI (#9495), and uses scalar vector math instead of the uncompiled Vector API, which was 6 to 27 times slower (#10072).
• Studio is served with a Content-Security-Policy that refuses inline script (#9681), and the saved-query and history sidebar, the Reference panel, the sample-database cards, the API endpoint list and the Profiler rows are keyboard accessible (#8740, #9375, #9508).
• HA operations: an operator override to lift a quarantine or the stale-snapshot read floor on a sole voter (POST /api/v1/cluster/accept-diverged/{database}) (#9449, #9498); GET /api/v1/cluster exposes the follower’s replication-path and unreachable-leader state and in-place restart counters, with matching alerts (#9399, #9429); an alert when every voter has quarantined the same database (#9553); the remaining Raft executors published as pool metrics (#8856); and a configurable DEFLATE level for snapshot ship (arcadedb.ha.snapshotCompressionLevel) (#9295).
• Backups: SQL BACKUP DATABASE applies the retention policy (#9844), and a full backup archives a vector index’s graph consistently so a restore reuses it (#9917).

Query Languages and Engine

• Native openCypher temporals: four new property types, OFFSET_TIME, LOCAL_TIME, ZONED_DATETIME and DURATION, indexable by LSM_TREE and HASH. A String is never reinterpreted as a time again (#8572, #9462, #9636).
• Customizable Contraction Hierarchies: a Graph Analytical View keeps a CCH per weight property (CREATE GRAPH ANALYTICAL VIEW ... CCH (distance)), so weighted point-to-point shortest paths no longer depend on the distance (cchShortestPath(), algo.cch.shortestPath), and the hierarchy keeps up with weight updates in milliseconds (#9437, #9915). This is the building block for route planning on large road and logistics graphs.
• path.* procedures answer as apoc.path.*: APOC’s filter syntax, nine uniqueness modes, endNodes, terminatorNodes, allowlistNodes, denylistNodes, optional, a lazy walk that a limit really stops, and a heap-charged breadth-first walk (#10025, #10048, #10049, #10017). Teams moving from Neo4j can check how much of the surface is covered on the Neo4j alternative page.
• openCypher label expressions on variable-length relationships ([:!R*], [:%*], shortestPath((a)-[:!R*]-(b))) now run (#9117).
• SQL: CREATE INDEX ... METADATA {"buildMode": "SORTED"} selects the sorted build (#9291); CREATE GRAPH ANALYTICAL VIEW v PROPERTIES () builds a view with no vertex properties (#9831); algo.labelpropagation takes a tieBreakProperty (#9285); CHECK DATABASE reports unreadable stripe directories (#9266); Gremlin hasLabel sees types created earlier in the same traversal (#9335).
• PromQL: the bool comparison modifier (a > bool 1) (#9644).

Remote Clients

• Typed “already exists” exceptions: the Java remote clients raise RemoteAlreadyExistsException for a taken user, token or database name, and the server answers 409 for them over HTTP (#10073, #10074, #10075).
• RemoteSchema.alterMaterializedView() is implemented, and a streamed error line rebuilds its typed exception (#8726, #8874).

Major Highlights

High Availability: Schema, Settings and Recovery Reach Every Node

If you run ArcadeDB in client-server mode with a Raft cluster, this release continues the hardening pass that started in 26.10.1.

• Changes that were saved on the leader only now replicate. ALTER PROPERTY constraints and the Property setters, schema extensions, the ALTER DATABASE date formats and setZoneId, ALTER TYPE ... WITH lightweight / unique, the time series downsampling policy, ALTER TYPE ... NAME (type, bucket, index and edge files), ALTER DATABASE / set database setting, a JSONL import’s triggers, views, continuous aggregates and functions, and db.migrateLegacyTemporals(). A constraint went unenforced on a node elected after a failover, and date settings answered differently per node (#9747, #9762, #9763, #9764, #9712). During a rolling upgrade a rename or a setting change is refused with 409 until every node understands it.
• Vectors inserted on a follower replaced other vectors. A replicated vector index page did not move the follower’s id allocator, so the next insert reused an id the leader had allocated: countEntries() stayed flat and the superseded vectors dropped out of search (#9428). A follower’s vector graph also picks up vectors replicated after its first search (#9857, fixed by @blaus23 in #9859), and a snapshot install or a full backup no longer reuses a vector graph without the manifest that vouches for it (#9758, #9888). Anyone running the GraphRAG stack on a cluster should take this fix.
• No leader after a leader loss in a 3-node cluster. Once a stopped node was gone, its host name could resolve to the node asking for it, so every Raft message meant for the dead node was delivered back to the sender and answered as if it were that node: the new leader received its own heartbeat and stepped down, and every election then counted its own vote twice. A node now refuses any Raft message addressed to another node and reconnects to a peer when it notices it has messaged itself (#10016, reported on a real cluster). A closed state machine refuses commits at once instead of waiting the quorum timeout (#9411), the Ratis close is bounded on stop() and on an in-place restart (#9561), and a log close can no longer deadlock with an in-flight cache eviction (#9556).
• An in-place Ratis restart double-applied a commit, and several replicated commit paths never fired after-commit callbacks, which also lost Redis transactions that only changed in-memory values (#8785, #8784).
• Two committed schema changes gave the same file id to different compacted index files, quarantining the database on every node (#9547). A restarted node ran out of heap catching up about 61,000 Raft entries on a 1 GB heap; the entry cache is now bound to the heap (#9549).
• A node removed from the Raft configuration no longer accepts writes that stall for the quorum timeout, and refuses consistent reads, drops and installs (#9510, #9590, #9589).
• The proposer of a refused schema entry is quarantined and resynced instead of staying diverged, and a bootstrap fingerprint entry applied during shutdown is left for replay (#9555, #9558, #9568). A sole voter no longer quarantines a database on an unexpected apply error (#9308).
• A schema change no longer breaks time series writes on followers: every schema reload closed the files of each time series type that held data, so the next write failed and the follower resynced (#9886).
• A follower’s refusal of leader-only work is answered at once (Database.transaction() used to retry it through every txRetries attempt) and always names the leader, never the refusing node (#9995, #10066, #10060). On the wire this is now a redirect: Bolt Neo.ClientError.Cluster.NotALeader, MongoDB 10107 NotWritablePrimary, Redis READONLY, and NOT_LEADER with the leader’s address on /ws and gRPC.
• The cluster credential on every peer dial is built in one place (PeerRequest), so the token and forwarded user always travel together (#9999, #10068).

Lost Updates and Silent Data Loss

• Index lookups lost a key while a commit published: a point lookup, Database.lookupByKey, pid IN :ids in SQL and in openCypher missed (11 to 23 percent of reads in the reproduction) or served another key’s record when a transaction deleted and re-created a key (#9369, #9397).
• A schema reload issued the same new page and RID to two transactions, because the reloaded bucket started with an empty page-reservation state (#9835).
• A schema change pending at close was lost whenever the schema held an index: the save ran after the database reported itself closed, failed at SEVERE and left the type or index gone after a reopen (#10059).
• LSM index compaction reset the null strategy to SKIP for ERROR and INDEX indexes, and saved it to schema.json (#9717).
• WAL recovery set the next transaction id from the last replayed transaction, not the highest, so after a crash with two concurrent commits the database re-issued transaction ids (#9795).
• include() / exclude() returned a dirty record stamped with the source RID, so saving a projection truncated that record and orphaned its edges (#9840). INSERT ... FROM SELECT *, !secret copied the excluded column (#9965).
• A MongoDB insert made while the caller held a transaction committed its own and rolled the caller’s back (#9977).
• A refused DELETE_RECORD had already removed the record’s index entries, EXTERNAL values and edges; the check now runs first (#9305). An edge iterator’s remove() unlinked an edge the user may not delete (#9779).
• A multi-page record could be read torn under REPEATABLE_READ after a concurrent rewrite (#9070), a flush suspension released on the wrong thread left every later backup, freeze and close timing out (#9832, #9927), and an async batch on a one-bucket type lost 1,000 records in 24 of 6,000 runs until its replay waited a jittered backoff (#9529, #9694).
• The Python driver rolls back after an interrupt in begin(), and run_in_transaction retries a LockTimeoutException, where 193 failures escaped in the reproduction (#9321, #9629, #9970). See ArcadeDB embedded in Python if you run the engine in-process.

Time Series and Prometheus: the Sealed Store Stops Losing and Resurrecting Data

If you use ArcadeDB for real-time analytics or as a Prometheus remote-write target, this section is the reason to upgrade.

• Retention appended its rewritten blocks after whatever an abandoned rewrite left in .ts.sealed.tmp, so blocks it had just dropped came back on the next open and shipped to every follower (#9770). COMPACT TIMESERIES TYPE racing a retention pass corrupted the live store’s in-memory directory and silently undid the retention at the next open (#9771). Acknowledged rows were missing after a kill -9 during a concurrent compaction (#9452).
• PRECISION SECOND lost every sample at the first retention pass, and a NANOSECOND type never expired and answered nothing in PromQL, because no timestamp code read the precision (#9800).
• Sealed store I/O: a thread interrupt closed the shared channel for every reader until the next compaction (#9621), and a short read dropped every later block of the directory (#9640).
• Writes are strict. An empty tag value, an undeclared tag or field key, a quoted datetime in a typed column and a value the column cannot store are refused or reported as a partial write instead of stored wrong (#8647, #8646, #9809, #9643). arcadedb.timeSeriesUndeclaredKeys restores the lenient behavior for schema-less producers.
• Reads: an unbounded SELECT FROM <timeseries type> and the gRPC stream no longer load the whole range (a 50M-point type ran out of heap) (#9420), scanRangeDescending no longer stops early on overlapping blocks (#9982), ts.rank ranks by value and ts.movingAvg keeps one slot per row (#9956, #9958), an ungrouped min()/max() of a LONG past 2^53 is exact (#9710), and count(*) is answered from block statistics (#9612).
• Prometheus: remote read keeps non-equality matchers and no longer merges series whose labels contain | (#9803, #9623), /series applies match[] (#9386), remote write converts labels into typed tag columns and answers 415 to a 2.0 body (#9972, #9624), and PromQL refuses what Prometheus refuses (#9723, #9743, #9788, #9883, #9922, #9924).

Equality and Typing Agree Everywhere

This continues the work from 26.10.1, where the index, SQL and Cypher were made to agree on what “equal” means.

• MERGE matches exactly what MATCH matches: a stored FLOAT, a temporal against a STRING property, and -0.0 / 0.0 no longer create duplicates or raise a duplicated-key error (#9693, #9616, #9617, #9618).
• A pattern finds what it stored in a declared scalar property. MERGE (n:S {v: 1}) stores '1' in a STRING property and used to create a duplicate every time; the same holds for text written into INTEGER, LONG, FLOAT, DOUBLE, BOOLEAN, DATE and DATETIME (#9695, #9701, #9794, #9935).
• A COLLATE ci index no longer changes the answer of = / IN (#9403), k = [1, 2] is no longer read as IN (#9370), SQL sum() of an empty group is NULL (#9351), and an equality on a ZONED_DATETIME property agrees with and without an index (#9648).
• Weighted shortest-path finders share one edge-weight rule: a missing weight is 1, and a negative, NaN or infinite weight is not walked, in dijkstra(), astar(), duanSSSP() and every algo.* finder (#9443).
• A statement is classified by everything nested inside it, so a write hidden in a LET, a projection or a sub-query is no longer run through the read-only paths (#9628).

A result set that changes after the upgrade is the fix, not a regression.

Faster Queries

Besides the plan cache and the admission gate described above, the engine got a round of speed work. For the numbers behind ArcadeDB’s engine speed, see the benchmarks.

• GROUP BY: each key is aggregated once in a parallel scan, aggregates are evaluated off bound columns, and the in-heap budget no longer scales with the number of cores (a query that ran on 1 or 2 cores failed on 4 or more) (#9496, #9402).
• Variable-length hops that need only distinct end vertices walk a visited set instead of every path: MATCH (a)-[:LINK*1..D]->(b) RETURN DISTINCT b over 200,000 vertices and 1.8 million edges went from not finishing at depth 9 in 120 s to about half a second at depth 12 (#10062, contributed by @tae898).
• LSM index scans no longer go quadratic after a hot key (#9461), bucket scan read-ahead is bounded by bytes (#9404, #9401), a commit skips the hole proof for pages written only by hole-free writes (#9483), and a scan stops paying a schema lookup per record (#9997, #10013).
• Count push-downs through a Graph Analytical View (LSQB Q2, Q3, Q7, Q8, Q9) take property predicates, Cartesian products and pass-through WITH, and are exact on parallel, reciprocal, self-loop and light edges (#9298, #9350, #9354, #9484, #9485, #9486, #9595, #9596, #9597, #9608, #9282).
• An index lookup that overlaps a commit no longer re-reads the whole key up to 9 times (#9902).
• Bolt coalesces RECORD messages into a few large socket writes (#9353) and no longer accumulates a whole PULL on the heap (#9372); a vector index rebuild is no longer deferred forever on a large index (#7260); the sparse top-K splits from 50,000 postings (#9482); and a time series grouped aggregation keeps its bucket cursor across rows (#10003).

Security

Authorization, redaction and input-bounds fixes found by audit and by reporters.

• Long-lived wire connections re-check the user (#9279). PostgreSQL, Bolt, MongoDB and Redis sessions re-resolve their user against the live security state on every request, as HTTP does: a deleted user, a changed password or a revoked grant now applies to connections that are already open. /ws insert and SUBSCRIBE frames do the same (#9311, #9312, #9340, #9424).
• SQL classification looks inside nested statements (#9628). LET $x = (INSERT ...), SELECT FROM (CREATE TYPE ...) and similar were reported as reads and ran through GET/POST /api/v1/query and read-only MCP identities. PROFILE follows the statement it wraps (#9313), and GraphQL type definitions need UPDATE_SCHEMA (#9280).
• Lightweight edge types enforce createRecord and deleteRecord (#9619, #9779); a vertex type’s super-node stripe buckets and a type’s paired EXTERNAL bucket follow the type’s permissions and lock (#9780, #9637).
• DELETE_RECORD is checked first, before any index or graph cleanup (#9305).
• LOAD CSV settings are security-sensitive (#9371): remote URLs, local files, the import directory and the blocked IP ranges need updateSecurity to change through ALTER DATABASE.
• Support diagnostics and logs redact arcadedb.server.defaultDatabases, including the JVM arguments uploaded to the portal and the two log lines that spelled the setting with a space (#9625, #9773). Rotate any password configured this way on a server that already uploaded diagnostics. Studio’s Support page no longer disables a column’s auto-mask for good after one unmask (#9797).
• Studio AI answers can no longer run HTML (#9626): the answer and the profiler analysis use an escape-first markdown renderer, marked is no longer shipped, and Studio is served with a Content-Security-Policy (#9681). The AI Assistant caps every read of the portal and gateway answers (#9627).
• gRPC: arcadedb.grpc.tls.enabled and the other arcadedb.grpc.* settings are read from server-configuration.json and the environment (asking for TLS in the file used to leave a plaintext endpoint listening), and arcadedb.grpc.host is honored (#9316, #9318).
• Production mode conceals error text on the Gremlin Server for every channelizer, on the /ws insert session, Bolt and Redis (#9317, #9639, #9749, #8749). The Python server’s loopback-by-default hardening now covers the Postgres, Redis and Bolt listeners (#9632).
• HA: security entries submitted from a node removed from the Raft configuration are refused (#9589).

Major Fixes and Improvements

Storage, WAL and Integrity

• A schema reload keeps the page reservations, an interrupted flush resume no longer abandons batches, dropping a database with suspended flushes releases its WAL acknowledgements, and closing the last database inside suspendFlushAndExecute no longer fails with a NullPointerException (#9835, #9832, #9881, #9927).
• A subtype that inherits an EXTERNAL property stores its values in its own _ext bucket (#9683). A compacted LSM bucket index keeps its name across a restart and an HA schema reload (#9213, #9434).
• CHECK DATABASE reads each record of a type with MANDATORY / NOTNULL properties once (#7981), and a failed read of a closed component file throws IllegalArgumentException instead of NullPointerException (#9306).
• Interrupted snapshot reads reopen the channel instead of invalidating open windows or aborting a backup (#9306); a full backup skips index-compaction temporaries (#8848); orphan compaction temporaries are swept at open (#8849).
• An impossible REGEXP, and a MANDATORY or default-valued property on a LIGHTWEIGHT edge type, are refused at declaration time (#9853, #9846, #9990, #9975).

SQL and Indexes

• LIKE '%' matches an empty string (#10005), values() on a sub-query row lists exactly the values of keys() (#9843), nested projection prefix wildcards @this:{s*} work (#9841), and a bare ORDER BY @rid on a MATCH that returns columns is refused instead of silently ignored (#9911).
• A MATCH node with rid: honors its type: and bucket:, and a node filtered by SEARCH_INDEX() is streamed instead of loaded whole (#9912, #9908). SEARCH_INDEX pushes @rid ranges and merges score-ordered OR branches before loading records (#9895, #9909, #10022).
• UPDATE ... UPSERT requires an equality on every property of a UNIQUE index (#9339, #9342); an async SELECT with parameters binds them, not the executor’s configuration (#9941); concurrent CREATE INDEX IF NOT EXISTS no longer fails with a NullPointerException (#9741); Schema.copyType no longer rolls back the caller’s transaction (#9851).
• The BM25 corpus counters of a FULL_TEXT index move when the transaction commits on every node and no longer race writers; the repair is kept and the counters are inspectable (#10018, #10019, #9337). SEARCH_FIELDS no longer matches terms in fields it was not given (#9910).
• vector.sum, vector.avg, vector.min and vector.max aggregate when written with the dotted name, in SQL and openCypher (#9768); sum() and avg() work over BYTE values, and agg.* functions accept Float[] and Short[] properties (#9281, #9777).
• A COLLATE ci index is skipped by native select() range cursors and Gremlin range has(), and select() with a LIMIT returns the rows the unindexed query does (#9302, #9613).

openCypher

• GQL constructs the parser accepted and the engine ignored are refused (ANY SHORTEST, REPEATABLE ELEMENTS, IS DIRECTED, a nested quantified group), a path variable over a quantified group binds one PATH, LET, IS NORMALIZED and the conditional query WHEN ... THEN run, and RETURN ... ORDER BY/SKIP/LIMIT is applied after the sort as one page (#9940). The full picture of what runs today is in ISO GQL in ArcadeDB: What Works Today.
• A variable-length MATCH honors a previously bound relationship list (#9828, #9854, contributed by @mvanhorn), WHERE (booleanVariable) is no longer parsed as a pattern (#9542), and a variable cannot be both a node and a relationship in a pattern predicate (#9292).
• DROP CONSTRAINT <name> drops what the constraint created, SHOW CONSTRAINTS / SHOW INDEXES list what exists, and IS :: <type> keeps the property’s other constraints and refuses attributes the new type cannot use (#9646, #9706, #9304, #9645).
• Write conflicts are retried by Database.transaction(..., retries) like SQL’s (#9487); temporal values compare under every dateImplementation and render with Locale.ROOT (#9647, #9649); durations are exact, ISO text is read as Neo4j reads it, and arithmetic raises on overflow (#9338, #10055).
• algo.bridges treats edges as undirected and algo.kShortestPaths takes a direction (#9766, #9914), and algo.* keeps tolerance and direction on the accelerated path (#9829).

Graph Engine and Analytical Views

• A view over only some of the vertex types no longer accelerates count push-downs, traversal, shortest paths or algo.* (#9301); a lightweight edge created or removed after the build reaches the view (#9572); a vertex whose edge list has an empty segment between non-empty ones no longer loses edges in the view or in CHECK DATABASE (#9715); parallel lightweight edges are distinct relationships in =, DISTINCT and DELETE (#10008).
• A view restored from its persisted CSR after a reopen gives the speed-up it reports (#9587), a fused 2-hop count(*) no longer holds every path on the heap (#9738), and a plain OPTIONAL MATCH ... WHERE h IS NULL plans as an anti-join (#9598).
• GraphBatch.withLightEdges(true) needs a LIGHTWEIGHT edge type (#9378).

Vector and Sparse Vector

• vectorNeighbors(), vector.neighbors, db.index.vector.queryNodes, vector.sparseNeighbors and vector.recommend (grouped or not) top up candidates that a concurrent commit deleted instead of answering short (#9368, #9858, #9697, #10002, #9692, #9396); the db.index.vector.queryNodes report is from @ofir-blaus.
• BINARY quantization reranks past deleted candidates and in grouped searches (#9633), vector.approxDistance INT8 keeps its per-vector scale (#9776), a sparse-vector update answers on its new dimensions (#9343), and FP16 and INT8 sparse searches no longer miss a document that belongs in the top-K (#9834).
• A location load that stops partway no longer lets new vectors reuse ids held by other records (#9892).

Wire Protocols

• Postgres: SHOW, DISCARD, DEALLOCATE, CLOSE and search_path are handled; START TRANSACTION, ABORT, BEGIN with isolation modes and AND NO CHAIN are accepted; statement_timeout is enforced; the extended protocol forwards a follower’s DDL and writes to the leader; and a write inside an explicit transaction on a follower stays inside it (#9326, #9327, #9328, #9329, #9631, #9954, #10040).
• Bolt: an index compaction left half-replicated no longer breaks every lookup with ArrayIndexOutOfBoundsException on a follower (#10046, reported by @rlaveycal).
• MongoDB: a MAP property with a non-String key no longer fails the whole find() (#9973), and a follower’s refusal is NotWritablePrimary (#9845).
• Redis: a MULTI/EXEC block retried by the HTTP auto-commit wrapper no longer applies INCR twice, HDEL reports the records it removed and a multi-key HDEL / HSET is one unit of work (#9322, #9837).
• gRPC: ExecuteCommand honors grpcQueryMaxResultRows (#9861), arcadedb.grpc.compression.enabled is applied (#9782), a lost answer on a write is an unknown outcome, not a retryable error (#8822), and ZONED_DATETIME, OFFSET_TIME, LOCAL_TIME and DURATION keep their type on the wire (#9969, #10034).
• GraphQL: selections that share a response key are merged, and a sub-selection on a LINK property is no longer dropped (#8744, #9467).
• Gremlin: elementMap() rows have one JSON shape, a nested map is named like the row (@rid, @type), the plugin fails its start on a port bind error, and the index step is guarded against a concurrent CREATE INDEX (#9576, #9781, #9319, #9651).
• HTTP: a statement longer than arcadedb.network.socketTimeout is no longer killed with no response (#9953), the write watchdog survives an XNIO selector wakeup race (#9439), and the streamed query error line carries the classified label and retryAfter (#8899).
• Remote client: SELECT @rid FROM Person and Gremlin elementMap() keep their metadata columns (#9804), and a malformed DuplicatedKeyException no longer crashes the driver (#9473).

Importer, GraphBatch and Async

• A 200M-vertex / 2B-edge GraphImporter load no longer stalls in pass 1 (#9575); an async executor batch waits a jittered backoff before replay (#9529, #9694).
• The native image resolves reflection-free SQL AST copies, Lucene and the missing function metadata, which fixed UPDATE/DELETE over HTTP answering 500 with NoSuchMethodException (#9495, reported by @zek0), and registers the gRPC messages and Netty’s ticker (#10070, #9564).

Python Bindings and Tooling

• The Python bindings are updated for 26.10.1: results that release the engine, exact Decimal and bytes parameters, and tripwires for open engine bugs (#9294, contributed by @tae898). An interrupt during begin() pops only the level it pushed (#9970).

Upgrade Checklist

Behavior changes are collected in the release notes, and the complete write-up, including the temporals migration recipe, is in docs/release-26.10.2.md. The ones worth checking before you upgrade:

1. The query admission gate is on by default (#9518). Past arcadedb.queryQueueTimeout or arcadedb.queryQueueMaxSize a request is refused as retryable (HTTP 503, Postgres 40001, Redis TRYAGAIN). Set arcadedb.queryMaxConcurrent=0 to disable it.
2. Docker images run on Java 25, and Studio is served with a Content-Security-Policy that refuses inline script (#9602, #9681).
3. HA:
   • The snapshot ship compresses at DEFLATE level 1 by default, so a resync over a WAN sends more bytes; arcadedb.ha.snapshotCompressionLevel=6 restores the previous level (#9295).
   • A follower restarted in place is no longer reformatted automatically (#8901).
   • During a rolling upgrade a type rename, ALTER DATABASE and set database setting are refused with 409 until every node runs this build, and a rename cannot be downgraded past this release on its retained log (#9762, #9763).
   • An index that already lost vectors to #9428 stays short and has to be rebuilt.
4. A follower’s refusal is a redirect: Bolt Neo.ClientError.Cluster.NotALeader, MongoDB 10107 NotWritablePrimary, Redis READONLY, /ws and gRPC NOT_LEADER with the leader’s address. A client that matched the old retryable codes must handle the new ones (#9845, #9868, #9930).
5. Queries that answered differently now answer consistently:
   • a plain = / IN on a COLLATE ci index is case sensitive (#9403);
   • k = <list> no longer expands (#9370), SQL sum() of an empty or all-NULL group is NULL (#9351), and UPSERT needs a UNIQUE index (#9339);
   • dijkstra(), astar() and the algo.* finders count a missing weight as 1 and skip negative weights (#9443);
   • MERGE and MATCH agree, and a declared scalar property matches the text it stored (#9693, #9695, #9794);
   • path.expandconfig and path.expand return every trail by default, and path.subgraphall returns every relationship between its nodes (#10025, #10048, #10049);
   • include() and exclude() return a map (#9840), values() on a Result follows keys() (#9843), a bare ORDER BY @rid on a MATCH with columns is refused (#9911), and a path variable over a quantified group binds one PATH (#9940).
6. openCypher temporals are stored natively. A database that holds Cypher temporals in undeclared properties reads them back as Strings until the property is declared with the new type and the values are copied through a parked property (#8572, #9636).
7. Stricter refusals instead of silent acceptance:
   • time series writes with an empty tag value or an undeclared key; arcadedb.timeSeriesUndeclaredKeys=ignore restores the old behavior (#8646, #8647);
   • an ISO duration with no component or a misplaced fraction (#10055);
   • an impossible REGEXP (#9853);
   • a MANDATORY or default-valued property on a LIGHTWEIGHT edge type (#9846);
   • a statement that hides a write inside a read (#9628);
   • GraphBatch.withLightEdges(true) into a type that is not LIGHTWEIGHT (#9378);
   • the GQL constructs listed above (#9940).
8. PromQL refuses what Prometheus refuses: a comparison between two scalars without bool, a set operator with a scalar, a range vector or a string as an operand, a scalar argument to abs, ceil, floor and round, and a range query that returns a range vector or a string (#9723, #9743, #9788, #9883, #9922, #9924).
9. Existing names answer 409: creating a user, a token or a database under a taken name no longer answers 403 or 400 (#10073, #10074, #10075).
10. Vector graphs: a snapshot install and a full backup now ship the .vecgraph empty, so the first search after a restore builds and verifies its own graph. Run REBUILD INDEX on the vector indexes of archives taken before this release (#9758, #9888).
11. Subtype EXTERNAL values written before the upgrade stay inline until REBUILD TYPE <Subtype> moves them (#9683).
12. Rotate passwords set through arcadedb.server.defaultDatabases if the server already uploaded diagnostics (#9625, #9773).
13. Smaller changes: the Gremlin Server in production mode refuses to start with a channelizer that cannot hide error details (#9639); BACKUP DATABASE now prunes the archive directory by the retention policy (#9844); arcadedb.grpc.compression.enabled=false is honored (#9782).
14. Embedded API: SQLFunctionHeuristicPathFinderAbstract.MIN is gone (use com.arcadedb.graph.EdgeWeight), Schema.alterMaterializedView() validates its arguments, and schema setters called directly on an HA follower throw the “schema changes need the leader” error (#9443, #8726, #9747). If you use ArcadeDB embedded, check these before you bump the dependency.

Dependency Updates

About 30 dependency bumps landed in this cycle, almost all through Dependabot. The notable ones:

• Server and engine: Netty 4.2.19, Undertow 2.4.4, Lucene 10.5.2, Jedis 8.0.2, JLine 4.4.7, snappy-java 1.1.10.11 and the PostgreSQL JDBC driver 42.7.14. The Docker base image moves to Eclipse Temurin 25.
• Studio: ApexCharts 7.8.0, swagger-ui-dist 5.33.1 and datatables.net 3.1.3; marked is no longer shipped (#9626).
• Build and test: Cucumber 8.0.4, Playwright 1.64, black 26.10.0 and the Go module bumps of the e2e suite.
• CI: GitHub Actions and pre-commit hook bumps.

Getting Started with 26.10.2

Docker

docker pull arcadedata/arcadedb:26.10.2

Visit our Docker Hub repository for more information.

Maven

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

All artifacts are available on Maven Central.

Documentation

For details on features and usage, see the documentation.

Download ArcadeDB 26.10.2 now: GitHub Releases

Thanks to everyone who reported, reproduced, reviewed, tested and fixed, in particular @ruispereira, @tae898, @manus-pi, @ofir-blaus, @blaus23, @mvanhorn, @willemijn-zeno, @shulei5831sl, @YaeSakuraQ, @Das-Rabindra, @HarinathMaddela, @saeedtabrizi, @zpaulo80, @zek0, @YGY-001, @ruslan-butyk-fntext, @rlaveycal, @preshewar and @philiptran-tech.

Luca Garulli ArcadeDB Founder

This post is the short version: how GQL fits into ArcadeDB, what you can use today, and where the gaps are.

How GQL runs in ArcadeDB

ArcadeDB has no separate GQL engine. GQL syntax runs inside the same native engine that implements OpenCypher 25, the latest Cypher grammar. That has two practical consequences:

• Nothing to switch on. You send GQL to the same Cypher endpoint you already use, over HTTP, the Bolt protocol or the Java API.
• GQL and Cypher mix freely. A GQL clause and a Cypher clause can sit in the same query, so you can adopt GQL one clause at a time.

What works today

Graph pattern matching with GQL quantifiers

Node and edge patterns, label expressions, OPTIONAL MATCH and GQL quantified edges all work:

MATCH (start:Station {name: 'A'})-[:NEXT]->{1,2}(stop:Station)
RETURN stop.name

->{1,2} is the GQL way to say “one or two hops”, the counterpart of Cypher’s *1..2.

Path modes: TRAIL, WALK and ACYCLIC

GQL path modes control whether a variable-length match may revisit edges or nodes. TRAIL (no repeated edges) is the default; ACYCLIC forbids repeated nodes; WALK allows both and needs an upper bound:

MATCH ACYCLIC (a:Person {name: 'Alice'})-[:KNOWS*1..5]->(b)
RETURN b.name

This query is also an example of mixing: a GQL path mode in front of a Cypher variable-length relationship.

FILTER, FOR and FINISH

GQL’s linear composition statements are supported:

MATCH (n:Person)
FILTER (n.age > 30)
RETURN n.name AS name

FOR name IN ['Alice', 'Bob', 'Carol']
CREATE (:Person {name: name})

FINISH ends a query without returning rows, which is handy for writes:

INSERT (n:Person {name: 'Bob'}) FINISH

INSERT and the rest of data modification

GQL INSERT takes a pattern, edges included:

MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'})
INSERT (a)-[r:KNOWS]->(b)
RETURN r

SET (labels included), REMOVE, DELETE, DETACH DELETE and NODETACH DELETE are all supported. Deleting a node that still has edges is refused unless you detach it.

Transactions and session parameters

GQL transaction statements run as plain statements:

START TRANSACTION

COMMIT

ROLLBACK works too, and so does choosing an isolation level with START TRANSACTION ISOLATION READ_COMMITTED (an ArcadeDB extension). Session parameters work over server sessions, HTTP or Bolt:

SESSION SET $base = 10

SESSION RESET and SESSION CLOSE are supported as well. These are not available in embedded mode yet.

What does not work yet

We would rather you find the gaps here than in production. Not supported in ArcadeDB 26.10.x:

• Search prefixes ANY and SHORTEST. The parser accepts them but does not apply them yet, so a query using them will not return shortest paths. Use shortestPath() and allShortestPaths().
• SIMPLE path mode and REPEATABLE ELEMENTS.
• LET, NEXT, EXCEPT, INTERSECT, OTHERWISE and USE graph. Use WITH where you would use LET.
• CAST. Use the toInteger(), toFloat(), toString() family instead.
• Unsigned integers, DECIMAL, BYTES and RECORD types. Use maps instead of records.
• CREATE GRAPH, GQL graph types and GQLSTATUS codes. One ArcadeDB database is one graph, the schema is ArcadeDB’s native schema, and errors over Bolt use Neo4j-style Neo.ClientError.* codes.

A few features are partial, such as quantified path patterns (fixed-length groups work, variable-length relationships inside a group do not) and IS TYPED. The coverage statement has the details, and the open items are tracked in issue #9940.

Why a coverage statement and not a conformance score

There is no public conformance test suite for ISO GQL yet. Without one, a database can only describe what it implements, so “GQL compliant” is not a claim anyone can check today. We publish the feature list instead.

The engine underneath does have a test score: the Cypher engine runs the openCypher Technology Compatibility Kit on every build and passes 97.8% of its 3,897 scenarios, with zero failures and the rest skipped.

ArcadeDB vs Neo4j on GQL

Neo4j also runs GQL inside its Cypher engine, and its GQL conformance appendix says Cypher supports most of the mandatory GQL features. One difference worth knowing if you are planning a move: Neo4j lists the GQL session and transaction statements (SESSION SET, START TRANSACTION, COMMIT, ROLLBACK) among the mandatory features not yet in Cypher and handles them through its driver API. In ArcadeDB they are query statements.

For everything else about moving from Neo4j, including the Bolt protocol, the importer and how your existing Cypher runs unchanged, see the Neo4j to ArcadeDB migration guide.

Try it

Start ArcadeDB with Docker and open the Studio at http://localhost:2480:

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

Pick Cypher as the language and any query in this post will run as written. If a GQL feature you need is on the missing list, tell us on GitHub: that list is what decides what we build next.

This post compares the two models on data modeling, querying, performance and operations, with runnable examples, and ends with a short checklist for choosing.

The short answer

• A relational database stores entities as rows in tables. Relationships are values (foreign keys) that a query matches up at run time with a join.
• A graph database stores entities as vertices and relationships as edges between them. A query traverses stored edges instead of computing matches.

If your important questions are about relationships, especially several hops deep or to an unknown depth, a graph database fits. If they are about sets of rows (totals, filters, reports) with shallow relationships, relational fits. Many applications have both kinds of question, which is why a database that offers both models in one engine is worth knowing about.

Data model: tables and keys vs vertices and edges

Take a small social network: people who know each other.

Relational model. Two tables. The relationship is a table of key pairs:

CREATE TABLE person (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE knows  (from_id INTEGER REFERENCES person(id),
                     to_id   INTEGER REFERENCES person(id));

A many-to-many relationship always needs a join table like knows. Any property of the relationship (when they met, how strong the tie is) becomes a column on that table.

Graph model. Two types: a vertex type for people and an edge type for the relationship. Properties can live on either.

CREATE VERTEX TYPE Person;
CREATE EDGE TYPE Knows;

CREATE VERTEX Person SET name = 'Alice';
CREATE VERTEX Person SET name = 'Bob';
CREATE EDGE Knows
  FROM (SELECT FROM Person WHERE name = 'Alice')
  TO   (SELECT FROM Person WHERE name = 'Bob')
  SET since = 2020;

That is SQL, running on ArcadeDB, which supports both SQL and the graph model. The edge is a record of its own, stored with links to the two vertices it connects, so the database never has to search for who Alice knows: it reads her edges.

Querying: joins vs traversals

Friends of friends (two hops) in relational SQL takes two joins on the link table plus joins back to person:

SELECT DISTINCT p3.name
FROM person p1
JOIN knows k1  ON k1.from_id = p1.id
JOIN knows k2  ON k2.from_id = k1.to_id
JOIN person p3 ON p3.id = k2.to_id
WHERE p1.name = 'Alice' AND p3.id <> p1.id;

In Cypher, the graph query language most graph databases support, the same question describes the path:

MATCH (a:Person {name: 'Alice'})-[:Knows*2]->(fof)
WHERE fof <> a
RETURN DISTINCT fof.name

Unknown depth is where the models really diverge. “Everyone Alice can reach through any chain of acquaintances” needs a recursive common table expression in SQL, which repeats a join on every iteration:

WITH RECURSIVE reach(id, depth) AS (
  SELECT k.to_id, 1
  FROM knows k JOIN person p ON p.id = k.from_id
  WHERE p.name = 'Alice'
  UNION
  SELECT k.to_id, r.depth + 1
  FROM reach r JOIN knows k ON k.from_id = r.id
  WHERE r.depth < 5
)
SELECT DISTINCT p.name
FROM reach r JOIN person p ON p.id = r.id
WHERE p.name <> 'Alice';

In a graph database it is a variable-length pattern:

MATCH (a:Person {name: 'Alice'})-[:Knows*1..5]->(b)
RETURN DISTINCT b.name

And shortest path is a built-in function rather than an exercise in recursive SQL:

MATCH p = shortestPath(
  (a:Person {name: 'Alice'})-[:Knows*]-(b:Person {name: 'Dave'}))
RETURN [n IN nodes(p) | n.name] AS names

The ArcadeDB query cheat sheet has these patterns and more in SQL, Cypher and Gremlin side by side.

Performance: why hops change everything

A join is computed: for each row on one side, the database finds matching rows on the other, typically through an index. Each additional hop is another join over the intermediate result, so the work grows with both the depth and the size of the tables involved.

A traversal reads relationships that are already stored with the record. The cost depends on how many edges the query actually touches, not on how large the tables are overall. That is why graph databases pull ahead on deep, branching queries and why the gap widens as hops increase.

We measured this directly on the LDBC Labelled Subgraph Query Benchmark, comparing ArcadeDB to PostgreSQL: across all nine queries ArcadeDB finished in 2.2 seconds against 69 seconds for PostgreSQL, and gaps of more than 150x on the two-hop friends-of-friends traversal and the star-shaped patterns. The full method, the queries and the caveats are in ArcadeDB vs PostgreSQL for graph queries.

The flip side is just as real: for scanning and aggregating one large table, or fetching a row by primary key, a relational database is excellent, and a graph database has no inherent advantage.

Schema and flexibility

Relational databases enforce a schema up front: every row of a table has the same columns, and changing the shape means a migration. That rigidity is a feature when data is regular and many applications share it.

Graph databases tend to be more flexible. In ArcadeDB, for example, Cypher and Gremlin create a type the first time you use a label, while SQL can declare properties, constraints and unique indexes when you want them enforced. You can start loose and tighten the schema as the model settles. Adding a new kind of relationship is a new edge type, not a new join table and a migration.

Transactions, tooling and maturity

Both families include ACID databases; ArcadeDB is fully ACID, and so are the major relational systems. Check this per product rather than per category.

Relational databases have decades of tooling: BI tools, ORMs, and a large pool of people who know SQL. Graph tooling is younger. Two things narrow that gap: graph databases that also speak SQL, and graph databases that implement the PostgreSQL wire protocol so existing drivers and tools can connect. ArcadeDB does both.

When to use a relational database

• Data is naturally tabular and regular.
• Relationships are shallow: one or two joins answer your questions.
• The workload is mostly aggregations, reports and CRUD by key.
• Your application depends on a specific relational product’s SQL dialect, stored procedures or extensions.

When to use a graph database

• The value is in the connections: fraud detection rings, recommendation engines that walk from users to items to similar users, identity and access management where permissions inherit through groups and roles.
• Queries need variable depth or paths: lineage, supply chains, network impact analysis.
• The model changes often and new relationship types appear over time, as in knowledge graphs.
• You are building AI retrieval that combines vector similarity with relationships, such as GraphRAG.

You do not always have to choose

Many systems have both kinds of question: an order table that needs monthly reports and a customer graph that needs traversals. The traditional answer was two databases and a pipeline to keep them in sync.

A multi-model database such as ArcadeDB stores tabular records, documents and graph edges in one engine, under one transaction, and lets you query them with SQL for reporting and Cypher or Gremlin for traversals. Our guide to what a multi-model database is explains the trade-offs of that approach.

ArcadeDB is open source under the Apache 2.0 license. The free ArcadeDB Academy has courses on both SQL and Cypher if you want to try the examples above hands-on.

This guide explains what a multi-model database is, how it differs from running several databases side by side, where it fits and where it does not, with examples in ArcadeDB, an open-source multi-model database.

What is a multi-model database?

A multi-model database is a single database engine that supports several data models natively and lets you query them together. Instead of choosing between a relational, document, graph or vector database, you get the models you need in one place, with one storage engine, one transaction manager, one security model and one backup.

The models you will meet most often:

A database is multi-model when several of these are first-class: you can create them, index them and query them without bolting on a second system.

Multi-model vs polyglot persistence

The alternative to multi-model is polyglot persistence: one specialized database per model. A typical stack might pair a relational database for orders, a document store for the catalog, a graph database for relationships, a search engine for text and a vector database for embeddings.

Each of those products may be excellent at its job. The cost is in the seams between them:

• Synchronization. The same customer now lives in several systems. Every write has to reach all of them, usually through change-data-capture or a message queue, and every pipeline is another thing that can lag or break.
• No shared transaction. If an order is written to one store and the relationship to another, there is no single commit. Failures leave the systems disagreeing until something reconciles them.
• Queries that cross models become application code. “Find documents semantically similar to this question, then follow the graph to the entities they mention” turns into two network calls and a join in your service.
• Operations multiply. Each database has its own backups, upgrades, monitoring, security model and expertise to hire for.

A multi-model database removes the seams: the records, edges, text index and vectors live in one engine and commit together.

What multi-model looks like in practice

In ArcadeDB, a vertex is also a document. It can hold nested objects and arrays, sit in a graph, and carry an embedding, all in one record:

CREATE VERTEX TYPE Customer;

CREATE VERTEX Customer CONTENT {
  "name": "Acme",
  "address": { "city": "Rome", "zip": "00100" },
  "tags": ["vip", "eu"]
};

-- document-style query on nested fields and arrays
SELECT name, address.city AS city
FROM Customer
WHERE 'vip' IN tags;

The same record can then be connected with edges and traversed as a graph. And because the vector index lives in the same engine, one query can retrieve by meaning and expand by relationships. This Cypher query finds the documents closest to a question embedding and returns the entities each one mentions:

CALL db.index.vector.queryNodes('Doc[embedding]', 5, $queryVector)
YIELD node, score
MATCH (node)-[:Mentions]->(e:Entity)
RETURN node.title AS title, score, collect(e.name) AS entities

With polyglot persistence, that is a call to a vector database, a list of IDs, and a second call to a graph database. In one engine it is one query and one round trip. It is also the core pattern behind GraphRAG: vector search finds the entry points, the graph supplies the context an LLM needs.

Several query languages over the same data is the other half of multi-model. ArcadeDB accepts SQL, Cypher, Gremlin, GraphQL, and the MongoDB and Redis query languages against the same records, so each team can use the language that suits the task. Our query cheat sheet shows the same tasks in SQL, Cypher and Gremlin side by side.

Native vs layered multi-model

“Multi-model” covers different architectures, and the difference matters for performance.

• Native multi-model. The engine implements each model directly: graph edges are stored as links between records, so following a relationship does not require a join or an index lookup per hop; documents are stored as documents; vectors live in a real approximate-nearest-neighbor index.
• Layered or emulated. One core model hosts the others. A relational database might store documents in a JSON column and answer graph queries by translating them into joins. That works for light use, but a deep traversal still pays the cost of a join per hop.

When you evaluate a product, ask how each model you care about is stored and executed, not only whether it appears on the feature list. Our comparison of ArcadeDB and PostgreSQL for graph queries shows the difference on a standard benchmark: graph patterns that compile to joins against the same patterns run on native graph storage.

Benefits of a multi-model database

• One transaction across models. A new customer, the edge to their company and their embedding commit together or not at all.
• No synchronization pipeline. There is one copy of the data, so nothing can drift.
• Cross-model queries. Filter on document fields, rank by text relevance or vector similarity, and traverse relationships in the same query.
• Fewer systems to run. One deployment, one backup, one monitoring setup, one set of credentials and permissions.
• Room to evolve. When the product needs a graph or semantic search next year, you add a type and an index, not a new database.

Trade-offs to consider

Multi-model is not automatically the right answer.

• Depth per model varies by product. A specialized engine may offer niche features a multi-model engine lacks. List the features you actually use and check each one.
• One engine is one failure domain. Consolidation reduces moving parts, but it also means the database’s high-availability setup carries more weight. Look at replication and failover as carefully as at features.
• Team familiarity. If your team knows one specialized database deeply and your application only ever needs that model, switching buys little.

When to choose a multi-model database

A multi-model database is a strong fit when:

• your data has relationships that matter and also needs document flexibility or search, as in a Customer 360 view that unifies profiles, interactions and accounts;
• you are building AI features that combine vector retrieval with structured context, such as GraphRAG or agent memory;
• you need consistency across shapes, as in fraud detection, where transactions, devices, accounts and their links must be evaluated together in real time;
• you want to cut the number of databases you operate.

If you already run a database and want to see how a multi-model engine compares, the Neo4j alternatives overview covers the open-source options, and ArcadeDB’s OrientDB migration guide covers the multi-model database it succeeded.

Try ArcadeDB

ArcadeDB is open source under the Apache 2.0 license, with graph, document, key-value, full-text search, vector and time-series models in one engine. You can run it embedded in a Java application, as a server, or as a cluster. The free ArcadeDB Academy courses walk through the models one at a time, and the GitHub repository has everything else.

At a Glance

Upgrading is recommended for every deployment, and in particular for every HA cluster. Behaviour changes are collected in the upgrade checklist below.

New Features

Server and Operations

• TLS/SSL for the Postgres wire protocol (#8840).
• Opt-in OTLP log export, an OTLP/HTTP metrics endpoint fix, and service.name in tracing (#7727, #7294, #7295).
• Persistent instance id (adb-<uuid>) shown in Studio, the arcadedb.support.id setting, and Studio support requests that run a read-only query support asked for and send the result back (#8685, #8682, #8861).
• A configurable config directory (#7415) and compact object headers enabled by server.sh when the JVM accepts them (#4537).
• HEAD on /ready and /health (#8133); the HTTP server binds every local address the configured host resolves to (#8692).
• Pool metrics for the per-server security executors (#7856).
• Read-your-writes bookmark (X-ArcadeDB-Commit-Index) on streamed HTTP responses (#7351), and streaming ingestion with a temporary-id mapping returned chunk by chunk (#7353).
• Startup restore: publishes progress and waits out a conflicting operation (#7440, #7652).

Studio

• Index search and time series move into Query and Database, with a new Chart tab (#8788).
• A selected saved query is no longer run automatically (#7049), and the cluster page shows peer capabilities and rolling-upgrade readiness.

Query Languages and Engine

• Property rename as an in-place primitive, in the Java API and SQL (#7589).
• COPY (<query>) TO STDOUT over the Postgres wire, in text and binary format (#7188), and NaN-transparent TimeSeries SUM/AVG (#7089).
• algo.personalizedPageRank takes a personalization vector (#8715); Cypher point() returns Neo4j SRIDs (#3993).
• TimeSeries: bucket origin/offset on ts.timeBucket, per-column codec syntax in CREATE TIMESERIES TYPE, and AggregationMetrics over HTTP (#8798, #7690, #7717).
• Graph Importer imports JSON array properties (vector embeddings) from JSONL (#7185).
• apoc.merge.node/apoc.merge.relationship onMatchProps and db.index.fulltext.query* options (#8117, #8103). Teams moving from Neo4j can see how much of the surface is covered on the Neo4j alternative page.

Remote Clients and gRPC

A spec-driven client generation epic (#4894) closed the gaps between the HTTP, gRPC and Java remote APIs: a gRPC control plane (database lifecycle, backup, security, profiler, restore and import, groups and API tokens), a gRPC time-series API, an HTTP streaming query and vector search, an HTTP//ws insert session with a Java client, and RemoteDatabase access to /ts/* (#7304, #7305, #7306, #7307, #7403, #7406).

Major Highlights

High Availability: a Hardening Pass on Every Path a Cluster Takes to Recover

Around 300 issues carry the ha label this cycle. The ones that mattered most in practice:

• A follower stuck at a stale term after a restart or rolling restart, costing quorum on the next failure, is fixed at the root: the leader looped on install-snapshot notifications for ever after a follower installed at leaderStart-1 (#8289, #8341, #8360, #8449).
• Stale entries after a snapshot install. A follower that re-applied its local log while a leader snapshot arrived applied stale entries onto the fresh copy and halted. Every install path now carries a boundary index, and a leader snapshot that is behind what the follower already applied is refused (#8577, #8579, #8454, #8651).
• A resync reopened pre-resync files. A snapshot resync skipped a database that was closed on the follower, a node could serve a snapshot of a database it had quarantined, and a node elected leader could reopen an unverified closed copy as the cluster’s copy (#8464, #8468, #8605, #8589). An audited override now exists for a peer that can never answer (#8641).
• Divergence after a graceful restart under load (extra rows and a corrupt unique LSM index) is closed (#8270), and so is a leader DDL that published its pages before its schema entry, so a concurrent replica transaction on the same pages merged against the old schema (#7438, #8686).
• Leadership hand-off. The automatic hand-offs only screened the target for lag, so a peer that was down was a valid target and the leader then refused every write. Targets are proven reachable now, the budget is sliced per candidate, and a node whose database was dropped for a resync can no longer be elected (#8556, #8491, #8533, #8480).
• A write that may have committed was retried. MajorityCommittedAllFailedException and ReplicationDispatchedTimeoutException were NeedRetryExceptions, so a committed write could be replayed (#8481). The remote client now sends X-Request-Id, so a write whose response was lost is retried safely (#8526, #8136).
• Readiness is honest. The security-convergence gate is armed on a runtime join, per join, and on by default; a node re-added with a retained config volume no longer passes it on stale fingerprints (#7819, #8317, #8329, #8414). Followers are gated on the leader’s commit index (#7619).
• Two concurrent add-peer requests could commit two Raft peer ids for one address (#7802), and the embedded addPeer API seeded no security documents at all (#7820).
• A long-running seeded chaos test now exercises compound failure and recovery scenarios (#8279), and the HA integration tests run nightly instead of on every push.

New on the HA side: a bulk schema scope so a DDL script replicates as one Raft entry, peer-capability negotiation, peer priority on POST /api/v1/cluster/peer, joining a running node to a cluster, and per-peer capabilities and rolling-upgrade readiness in Studio (#6990, #7219, #7523, #7515, #7538). If you run ArcadeDB in client-server mode with a Raft cluster, this is the release to be on.

Lost Updates and Silent Data Loss

• SET n = n + 1 lost an increment under READ_COMMITTED when two transactions committed concurrently (#8538). A write computed from a read that went stale is now refused (#8610).
• Concurrent updates of records that grow past a page lost committed updates in most runs with txPageSlotMerge on (the default), and a document larger than one page was silently overwritten (#8985, #8982, #8988, #8989).
• HASH indexes applied a key change twice at commit: UNIQUE_HASH let an UPDATE take a key another record held, and NOTUNIQUE_HASH kept a stale entry (#8983).
• UPDATE ... SET on a nested map key or list index was silently lost, because the owner was never marked dirty (#8027); UPDATE ... REMOVE prop[0] on a Set deleted every element (#8032).
• One interrupted commit permanently killed a WAL pool slot, so every later transaction on it blocked 30 s and failed (#7768).
• A UNIDIRECTIONAL edge created while its target was deleted committed as a ghost edge (#8986, #8676).
• DROP TYPE left the type’s aliases in the schema, so the dropped type came back alive after a restart (#8169); TRUNCATE TYPE never refused a non-empty vertex or edge type (#8042).
• Console data loss. The console split a command at the first closing brace followed by a newline, so a multi-line UPDATE ... SET x = {json} ran with no WHERE and overwrote every row (#8246).
• Clean close and WAL. A clean close now fsyncs only the files written since their last sync, and recovery fsyncs before it drops the WAL; a second embedded instance’s clean close could delete another live instance’s files (#8626, #7479, #7502); and a WAL housekeeping timer could delete recovery input (#8600).
• The schema is written once per DDL statement, never mid-transaction, and schema.json is replaced atomically (#8635, #7279).

The Same Value Now Compares Equal Everywhere

The index, a SQL scan and Cypher disagreed on what “equal” means for several types, so the same WHERE returned different rows depending on the plan. They agree now for FLOAT/DOUBLE, DECIMAL, DATETIME, BOOLEAN, BigInteger, signed zero and null (#8884, #8885, #8886, #8887, #9113, #9114, #9160, #9274).

• Null equality is decided at execution, not at planning. A statement first run with a value kept its index plan, so a later run with null returned the null-key records again, and a DELETE could remove the wrong rows (#9274, #9238). UPDATE/DELETE with positional parameters read the WHERE from an earlier cached statement (#9245).
• Precision. A SQL decimal literal keeps digits beyond double precision, JSONL import keeps DECIMAL precision, a suffix-less floating point literal is a Double, and numeric comparison past 2^53 is exact (#8872, #8871, #7609, #7628).
• Datetimes. An unparseable datetime is refused instead of stored as NULL, and DATETIME_MICROS literals with a space separator stop being truncated (#8090); sub-millisecond precision and temporal round trips were fixed in Cypher and over the wire.
• Aggregates. LONG sum overflow, COUNT(DISTINCT expr) (a syntax error until now), aggregates in ORDER BY, and min()/max() over an index range (#8972, #8889, #8973, #8812).

A result set that changes after the upgrade is the fix, not a regression.

Faster Queries

• Parallel scans, aggregation and DISTINCT. Filtered scans and aggregation run on the dedicated scan workers, a transaction that has written nothing still scans in parallel, POST /query no longer opens an auto-commit transaction that blocked it, and a satisfied LIMIT releases its upstream (#8523, #8775, #8594, #8799, #8797). Scans also stopped re-resolving each record and build records from the page in hand (#8265, #8266, #8312).
• The index serves more shapes: Cypher ORDER BY ... LIMIT from index order, LIKE 'prefix%', STARTS WITH, Cypher min()/max(), Cypher OR index seeks, case-insensitive index ranges, and an adaptive range fetch that parallelises large ranges (#8422, #8666, #8723, #8766, #8333).
• Concurrent RID lookups scale. The database read/write lock is striped (#8838), and checkDatabaseIsOpen no longer writes lastUsedOn on every call (#8523).
• Plan caching. UPDATE, DELETE and INSERT no longer re-plan on every execution (#9207), and a correlated LET subquery is memoized per outer binding (#8400, #8441).
• Graph algorithms. algo.wcc uses a parallel union-find (Afforest) (#9133), and algo.* waits for the restored Graph Analytical View on the first call after a reopen (#9220).
• Cypher joins on disconnected patterns use a value hash join with compact, bounded buffers instead of buffering the full record of every right-hand row (#8583, #8584, #8585).
• A JVM-wide heap budget for query buffers keeps concurrent SQL and OpenCypher queries from exhausting the heap together (#8591).
• TimeSeries: tag-skipping mutable scans, merging of small sealed blocks, shared tag strings and bucket origin/offset for weekly buckets (#8574, #8798, #8794, #8793). For the numbers behind ArcadeDB’s engine speed, see the benchmarks.

Vector and Sparse Vector Search

Teams building retrieval pipelines on the GraphRAG stack get a round of correctness fixes in LSM_VECTOR and LSM_SPARSE_VECTOR:

• The graph rebuild loop stops when two records share a vector id, and CHECK DATABASE FIX repairs it (#8946).
• Aborted transactions no longer leak tombstones or uncommitted vectors into vector indexes, a rebuild reads committed state only, and a delete reuses the persisted graph (#7931, #7974, #7842).
• Searches during an async rebuild returned poor neighbors; the first search after a reopen loads the graph via the ordinal map; a query that rebuilds a graph honours the JVM-wide rebuild limit (#8862, #8852, #7814).
• A filter that matches no records was treated as no filter and returned records outside it (#8959); grouped search fills every winning group (#8002).
• Compaction lost commits and a search during compaction was wrong; BINARY quantization, zero and non-finite vectors, and a window-based MaxScore for SPLADE top-K were fixed (#9132, #9252, #9200).
• The HNSW build cache is sized from the heap ceiling, so a served database matches an embedded one (#7146).

New: vector.neighbors accepts a subquery result as its filter, dense vector search sees the open transaction’s rows, and sparse-vector indexes can be built over existing rows and rank by exact score (#7125, #7378, #8536, #8576).

Wire Protocols: TLS for Postgres and 100+ Fidelity Fixes

• TLS/SSL for the Postgres wire protocol (#8840), plus COPY (<query>) TO STDOUT in text and binary format (#7188).
• Postgres: SET is session-scoped, transactional and read back by SHOW; COMMIT/ROLLBACK inside an implicit transaction block were silently ignored; a trailing semicolon bypassed the transaction-block state machine; ROLLBACK TO SAVEPOINT is refused instead of accepted as a no-op; portals are transaction-scoped; $N parameters work on indexes; the Arrow ADBC driver bootstraps (pg_type, regclass); and binary arrays work (#8028, #8245, #8217, #7178).
• MongoDB: lossless BSON types (Binary, regex, timestamp, MinKey, MaxKey and JavaScript were silently dropped), exact filter semantics, nested $set, projection, unique _id and replace (#9062, #9137).
• Redis: a newline batch was classified by its first command only, so a GET followed by an HDEL was declared read-only; INCR/DECR are atomic on the query engine too; MULTI/EXEC no longer double-applies; values are binary-safe; INCRBYFLOAT is supported (#8247, #8248).
• Bolt: node ids match id(n), system procedures are served only when the statement is that call, and failures are named.
• gRPC and remote clients: a lost response on a self-committing write is an unknown outcome, not a retryable error; RemoteDatabase.transaction() has the partial-commit guard; RemoteServer drop/createUser/dropUser go through httpCommand (#8525, #8062, #7796).
• Gremlin: label loss, profile double execution, idempotent drop, fractional index bounds and the advertised Gremlin port were fixed (#8258, #7408, #9147).

Security Advisories

This release closes four security advisories, published in full (impact, affected versions and credit) as GitHub Security Advisories on the repository. All four affect 26.9.1 and earlier, are patched in 26.10.1, and were reported by @manus-pi.

• GHSA-h2j4-28h8-cj5v (critical): the Gremlin Groovy engine lacked a scripting authorization check, enabling remote code execution by an authenticated user.
• GHSA-7fcg-pg8x-wf7w (medium): Bolt SHOW DATABASES listed every database on the server without per-user authorization filtering.
• GHSA-hw9x-xx38-rg28 (medium): Bolt lacked per-database authorization, so an authenticated user could read another database’s schema metadata.
• GHSA-9c7g-grf7-j2r5 (medium): read-only users could change edge type lightweight/unique schema flags via ALTER TYPE, bypassing UPDATE_SCHEMA.

Also Hardened in This Release

• Bolt applies the per-user database and type access to database selection and schema listings (#8415).
• Schema DDL gates: ALTER TYPE edge-type settings and REBUILD TYPE require UPDATE_SCHEMA (#8398).
• Gremlin scripting is restricted further, including io() and lambdas (#8227, #8338).
• Request bounds: a chunked request body no longer bypasses httpBodyContentMaxSize, gzip and Snappy ingest are bounded after decompression, and /ws frames are bounded (#7772, #8084, #8065). MongoDB wire regexes in aggregation are time-bounded (#9164), and a TimeSeries aggregation checks its caller’s ceiling before allocating buckets (#7476).
• Secrets: set_server_setting and the MCP request log mask hidden settings, and resetAll() no longer dumps the whole configuration (#8038, #8965).
• AI chat store: the legacy-directory migration no longer awards a collided chat store to the wrong user, and accounts that differ only in case no longer share one (#7620, #8154).
• HA: five TLS and security issues were fixed, security mutations are refused off the leader, and the Raft gRPC peer allow-list is no longer frozen at startup (#7854, #8407, #7162).
• HTTP Basic credentials are split on the first colon only (#7783).

Major Fixes and Improvements

Storage, WAL and Integrity

• A write to a record the transaction already deleted is dropped, not reported as a deadlock (#7149).
• Bucket space reuse, a free tail measured directly on a rebased delete, and edge delete page merges were fixed (#8660, #8401, #9233).
• LIGHTWEIGHT edge types: reads answered 0, and TRUNCATE and TRAVERSE were wrong (#7477, #7480, #7481).
• CHECK DATABASE finds records that violate their own type’s existence constraints (#7952), and a failed REBUILD INDEX restores the old index (#9254).
• A LIMIT query could leave the database unable to close because cancelling its parallel scan interrupted a page read (#8944).
• Windows backup archive nesting and path separators were fixed (#7586), and the ext4 lost+found directory is no longer registered as a database (#8805).
• Backups cover the configuration files in the snapshot (#6114), and the HA snapshot ZIP skips index-compaction temporaries (#8019).

Indexes

• A range seek landed in the middle of a same-key run (#7611); transaction index ranges after compaction and the tx-overlay filtering rules shared across read paths were fixed (#8817, #6970).
• CREATE INDEX on a populated type no longer truncates datetimes to milliseconds, and CREATE INDEX IF NOT EXISTS works across super types (#7164, #7228).
• SQL queries no longer fail while an index is created or dropped on the same type (#8855).
• Hash index overflow walk cost, prefix seek and lookup at page end were fixed, along with unique prefix lookup and IS NULL on unique indexes (#9253, #8806).
• A unique BINARY key skipped the uniqueness check because array keys were compared shallowly (#7881).

SQL

• Parser re-render, copy(), LIMIT counting, positional LIMIT ? SKIP ? binding, comments in ORDER BY/GROUP BY, hex literals, nesting guards and planner exceptions were fixed (#7800, #8434, #9122, #9154).
• A scalar left operand of CONTAINSANY silently matched nothing, and expand() of a native array yields one row per element (#8475, #7910).
• The UPDATE Halloween problem, GROUP BY projection alias rebuilt per record, ORDER BY over a null scan, and FULL_TEXT never answering exact lookups were fixed (#8814, #8260, #8664, #8442).
• SQL scripts replay blocks correctly, and EXPLAIN has parity across sqlscript operation types (#8633, #7576).

openCypher

• Relationship uniqueness is scoped to the clause, MERGE binds the path it merged, and an eager read/write barrier means a query never reads back what it just created (#7165, #7169, #7171).
• MERGE ... ON MATCH SET no longer loses a concurrent increment, nodes are written once for MERGE ... SET and CREATE ... SET, and LIMIT after a write no longer cuts the write short (#8538, #8735, #8826, #8827).
• An empty FOREACH changed OPTIONAL MATCH results; FOREACH/REMOVE scope checks, existence constraints checked at end of statement, and CALL (*) no longer inheriting the outer clauses’ variables were fixed (#8733, #8105, #9205).
• Unidirectional in()/both() with a view, queries on the incoming side of unidirectional edge types, DELETE of a node with several relationships, and code-point string handling were fixed (#8939, #8625).

TimeSeries

• A TIMESTAMP column not declared first round-tripped through JSONL with its values in the wrong columns (#7899), and aggregation push-down mixed row and schema column indexes between the mutable and sealed halves (#8140).
• A query now gives one answer whichever layer holds the data; sealed-store identity and repair were fixed, and an empty TAG key is refused instead of dropped silently (#7733, #8738, #8563).
• PromQL conformance gaps were closed, and ts.timeBucket() is exposed as LocalDateTime (#8926, #7610).

Importer, GraphBatch and Async

• Importer transaction ownership, RDF and CSV edge cases, row-error handling and post-import validation were fixed (#7943, #7948).
• GraphBatch wrote the header end offset one byte short on property-less edges, wrote a null for a declared edge property as a type tag with no value, and now honours the caller’s transaction (#7448, #9018, #9242).
• A periodic batch-commit conflict is retried instead of silently discarded (#7615), and insert_many and GraphBatch.create_vertex roll back on every failure path (#7882).

Upgrade Checklist

Behaviour changes are collected in the release notes. The ones worth checking before you upgrade:

1. Security-convergence readiness gate is on by default on HA clusters, armed per join. A joining node is not reported ready until its security state matches the leader’s (#7819, #8414).
2. arcadedb.server.apiTokenRequireSecureTransport: check the first-run Docker flow on http://localhost:2480, where Studio’s API-token mint is refused once it is on (#8765, #7804).
3. Stricter refusals instead of silent acceptance: an unparseable datetime, a map value the declared type cannot take, Type.convert of an impossible value, ROLLBACK TO SAVEPOINT over the Postgres wire, an UPDATE whose value was computed from a stale read, and TRUNCATE TYPE on a non-empty vertex or edge type (#8090, #9110, #8610, #8042).
4. Queries that returned a plan-dependent answer now return the equality-consistent one (null keys, FLOAT/DECIMAL/DATETIME/BOOLEAN, signed zero).
5. Index default page size changed (#9250); existing indexes keep their size.
6. Schema DDL gates: ALTER TYPE edge-type settings and REBUILD TYPE need UPDATE_SCHEMA (#8398); Gremlin scripting and io() are restricted (#8227).
7. Rolling upgrade of an HA cluster: peers negotiate capabilities, and group or API-token changes wait until every peer supports them; Studio’s cluster page shows the state (#7219, #7538).
8. LSM_SPARSE_VECTOR rescoring oversamples by default (rescoreOversample 2) and ranks by exact score (#8576).

Dependency Updates

About 140 dependency bumps landed in this cycle, almost all through Dependabot. The notable ones: Netty 4.2.18, Apache Ratis 3.3.1, Gremlin (TinkerPop) 3.8.2, GraalVM 25.x, JVector 4.0.1, Jackson 2.22.3, Protobuf 4.36.2, SLF4J 2.0.20, Logback 1.6.5, OpenTelemetry 1.66.0, SnakeYAML 2.7, lz4-java 1.12.0, commons-lang3 3.21.0, JLine 4.4.6, Neo4j Java driver 6.3.0, Jedis 8.0.1 and gRPC protos 2.78.0. On the Studio side: ApexCharts 7.6.1, marked 18.0.14 and swagger-ui-dist 5.33.0.

Getting Started with 26.10.1

Docker

docker pull arcadedata/arcadedb:26.10.1

Visit our Docker Hub repository for more information.

Maven

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

All artifacts are available on Maven Central.

Documentation

For details on features and usage, see the documentation.

Download ArcadeDB 26.10.1 now: GitHub Releases

Thanks to everyone who reported, reproduced, reviewed, tested and fixed, in particular @ruispereira, @tae898, @rspereiratech, @YGY-001, @jjj-n, @gramian, @Das-Rabindra, @singhpratech, @rlaveycal, @wkpark, @rbonestell, @justinblethrow-cloud, @philiptran-tech, @GYWang1983, @astarso, @mdre, @ivan-velikanov, @willemijn-zeno, @shlomiassaf, @nx-mama, @maurovit, @LetMeSleep8h, @suhanrain, @manus-pi, @BingEdward, @anatshad, @borutjures, @ExtReMLapin, @jawahar4k, @JMQuill-SF, @M-Tesla, @odysseaspenta, @sainiteesh36, @shulei5831sl, @singh-hovr and @wsalembi.

Luca Garulli ArcadeDB Founder

But when the use case is a real graph, it is not the best choice. Not even close.

That needs saying now, because when the PostgreSQL 19 betas shipped SQL/PGQ, the ISO SQL:2023 standard for property graph queries, one conclusion spread fast: PostgreSQL is a graph database now. “You don’t need Neo4j.” “I ran our Neo4j workload against it.”

Then, on September 7, 2026, the feature was reverted from PostgreSQL 19 over stability concerns. The earliest it can return is PostgreSQL 20, in September 2027.

The delay is not the interesting part. SQL/PGQ will land eventually, and the real question is: once it does, can PostgreSQL replace a graph database for a real graph workload? We ran the LDBC LSQB benchmark to find out. ArcadeDB finished all nine queries in 2.2 seconds. PostgreSQL needed 69.

What SQL/PGQ in PostgreSQL Actually Is

SQL/PGQ lets you declare a property graph over tables you already have, and query it with a pattern instead of a stack of joins. That is a genuine readability win. But the exobench analysis of the beta is clear about what it is: “deliberately not a graph storage engine. It is a rewriter.” Every MATCH compiles into the joins you would have written by hand, with identical execution plans.

The beta also left out most of what graph work needs:

• No variable-length paths: quantifiers like {1,5} were rejected.
• Read-only: writes go to the underlying tables, in plain SQL.
• No graph algorithms: no PageRank, no community detection.
• Schema-bound: every edge type is a table, declared up front.

Syntax Is Not Storage: Joins vs Index-Free Adjacency

In PostgreSQL, an edge is a row, so every hop is a B-tree search that gets slower as the table grows. In ArcadeDB, each vertex holds direct links (Record IDs) to its edges, so a hop is a pointer jump whose cost does not depend on the size of the database. That is index-free adjacency. The difference is invisible at one hop and dominant at three.

The Benchmark: LDBC LSQB, ArcadeDB vs PostgreSQL

LSQB is maintained by the Linked Data Benchmark Council, not by us: nine pattern-matching queries, with an official SQL version for relational systems and an official Cypher version for graph systems. We ran it at scale factor 1 (3.9 million vertices, 17.9 million edges). Since GRAPH_TABLE compiles to the same plan as those SQL joins, PostgreSQL’s numbers are exactly what SQL/PGQ would get.

ArcadeDB wins all nine, and the gap follows the shape of the query:

• Short patterns (Q2, Q5): 1.8x to 3x. Hash joins work here, and PostgreSQL does fine.
• Friends of friends (Q6): 161x. Only two hops, but 1.67 billion matches: 17.7 seconds of self-joins against 110 milliseconds of walking adjacency lists.
• Stars (Q4, Q7): hundreds of times. Every arm of the star is another join in PostgreSQL, and just another neighbor list of the same vertex in ArcadeDB.

The Memgraph team found the same curve on a different dataset: comparable up to three hops, a PostgreSQL timeout at five.

Beyond Fixed Patterns: What PostgreSQL Can’t Express Yet

LSQB uses fixed-length patterns only, the best case for SQL/PGQ. Real graph applications go further:

• Variable-length paths. “Within five hops of a known fraudster” needs a recursive CTE in PostgreSQL: 2.2 seconds on a 1 million node graph, and 6 seconds with emulated SQL/PGQ recursion, per exobench. In ArcadeDB it is one line: MATCH (a)-[:TRANSFER*1..5]->(b).
• Graph algorithms. None in PostgreSQL. ArcadeDB is fastest on 5 of the 6 LDBC Graphalytics algorithms, with PageRank in 0.10 seconds.
• Writes through the graph. CREATE and MERGE are ordinary transactional writes in ArcadeDB; in PostgreSQL the graph is a read-only view.
• New relationship types. A new edge type in ArcadeDB; a new table, a migration, and an ALTER PROPERTY GRAPH in PostgreSQL.

“But I Don’t Want Another Database”

That is the real appeal of SQL/PGQ, and it is fair. But if the goal is one database, it doesn’t have to be PostgreSQL. ArcadeDB is a complete ACID DBMS, not a graph add-on: relational records with schemas and constraints, plus graph, documents, vectors, full-text, time series, and geospatial data in the same transaction. That is also what makes it a natural fit for GraphRAG.

Your team keeps its tools: psql and PostgreSQL drivers connect over the wire protocol. One honest caveat: queries are ArcadeDB SQL or Cypher, not PostgreSQL’s SQL dialect. So:

1. PostgreSQL alone when relationships are a minor feature.
2. ArcadeDB alone for new applications or modest schemas: one engine, nothing to sync.
3. PostgreSQL plus ArcadeDB when an app is deeply tied to PostgreSQL SQL, PL/pgSQL, or extensions: keep it, and move the graph part, such as fraud rings, knowledge graphs, recommendations, access paths, or supply chains, into ArcadeDB.

PostgreSQL vs ArcadeDB: An Honest Guide

If relationships are a feature of your application, SQL/PGQ will be a welcome upgrade whenever it ships. If relationships are your application, a relational engine with graph syntax is still a relational engine.

Try It Yourself

The queries, datasets, and harness are public: see the benchmarks page and the runner on GitHub. If your numbers differ, send them to us. To try your own workload:

docker run --rm -p 2480:2480 -p 5432:5432 \
  -e JAVA_OPTS="-Darcadedb.server.rootPassword=playwithdata -Darcadedb.server.plugins=Postgres:com.arcadedb.postgres.PostgresProtocolPlugin" \
  arcadedata/arcadedb:latest

Then connect with psql, or open the Studio at http://localhost:2480 and write your first MATCH.

A Tom Sawyer Software graph analytics dashboard built on demo crime-network data: entity relationships, a full network graph, and linked incident charts, all views over the same connected data. Image: tomsawyer.com.

Tom Sawyer Software has built graph analytics and visualization tools for over three decades, and picking a database to sit underneath a commercial engineering product is not a decision made lightly. The Apache 2.0 license is a big part of why: customers get an open-source database with no proprietary licensing cost, and can still add commercial support with SLAs for production environments if they need it.

What Digital Engineering actually does

The suite targets a familiar problem in large engineering organizations: requirements, system models, processes, and change history end up scattered across disconnected tools, and nobody can trace a decision from one end of the product lifecycle to the other. Tom Sawyer Digital Engineering is built to break down those silos with six modules:

• Planning, for visual dependency and change-impact analysis.
• Business Process, a BPMN 2.0-compliant workflow designer and execution engine.
• Model-Based Engineering & SysML v2 Viewer, which generates diagrams automatically from system models.
• Data Streams, real-time ETL for normalizing data coming from disparate sources.
• Perspectives, a low-code platform for building custom knowledge graph applications on top of the same data.
• Explorations, a no-code interface for querying the graph database directly, aimed at business stakeholders rather than engineers.

Every one of those modules is a different way of looking at the same underlying graph: a requirement connects to the system model element that implements it, which connects to the process step that changes it, which connects to the person who approved the change. That is exactly the kind of interconnected, schema-flexible data a graph database is built to hold, and it is why a suite spanning six different front ends can share one backbone instead of six separate stores.

Why this fits ArcadeDB’s model

Tom Sawyer Software’s page frames ArcadeDB specifically as a graph database, but ArcadeDB is multi-model underneath: the same engine that stores the graph also handles document, key-value, search, vector, and time-series data without a separate database to run or a separate query language to learn for each. For a suite where traceability, search, and analytics all touch the same records, that means Digital Engineering does not need to bolt on a second system when a module needs something other than graph traversal, whether that is full-text search over requirements or vector similarity for finding related model elements.

Digital Engineering is a web-based suite, which means it talks to its data store the way most web applications do: as a client-server deployment rather than an embedded library. That is the deployment mode ArcadeDB was built to run in, alongside the embedded mode used when a database needs to live inside another application’s process.

An open-source backbone, with a commercial path

The detail worth underlining is the licensing structure Tom Sawyer Software chose to build on. ArcadeDB’s Apache 2.0 license means Digital Engineering customers are not paying a database vendor on top of paying Tom Sawyer Software, and are not locked into a proprietary format if they ever want to inspect or migrate their own data. For teams that need guarantees beyond what a community can offer, commercial ArcadeDB support with service-level agreements is available as a separate, optional layer, so the choice of open source under the hood does not mean going without a support contract for production.

If you are evaluating a graph database for graph analytics of your own, rather than through Tom Sawyer Software’s suite, the same traversal, pattern-matching, and multi-model engine described above is available directly: SQL, Cypher, and Gremlin against the same records, embedded or client-server, under the same Apache 2.0 license.

The short version

In August a new client stack started exercising ArcadeDB’s PostgreSQL wire protocol: Apache Arrow’s ADBC API, through adbcBridge and the standard PostgreSQL ODBC driver, and separately through Arrow’s own native PostgreSQL driver.

Over three weeks that testing found four gaps in the protocol implementation. ArcadeDB fixed the first in four and a half hours, the second in nine days, merged an external fix for the third the day it arrived, and opened the fourth on its own tracker with a root cause on the same day it was raised.

The wire protocol held up. Where it did not, the response was the story.

The four findings

1. The Arrow native PostgreSQL ADBC driver could not connect (#7178). That driver bootstraps its type table with a query against pg_catalog.pg_type, and ArcadeDB answered it with zero columns. Raised as a follow-up in discussion #6888; the maintainers opened the issue themselves at 22:11 UTC on 2026-09-05 and closed it, fixed, at 02:48 UTC on 2026-09-06. Four hours and thirty-seven minutes.

2. COPY (query) TO STDOUT was not supported (#7188). The native Arrow driver reads every result through binary COPY by default, so after the first fix it connected and then stopped at the first result set. Opened 2026-09-06, implemented in text and binary form and closed 2026-09-15. With that, Arrow’s own PostgreSQL driver reads ArcadeDB main with default options.

3. Transaction-control statements answered with a row description (#7815). On the simple-query path, BEGIN, COMMIT, ROLLBACK and the savepoint statements were sent with an empty RowDescription before CommandComplete, so libpq reported a result set where it expected a command status. psql printed an empty table after BEGIN, and clients that start with autocommit off could not open a transaction at all. Sent as a pull request from the adbcBridge side on 2026-09-17, reviewed and merged the same day by a maintainer, who added a follow-up commit of his own.

4. A datetime literal with a space separator and a fraction is stored as NULL (#8090). '2024-02-29 13:45:10.123456' is the form psqlodbc renders a bound timestamp in. The space alone parses, the fraction alone parses, both together fail to parse, and a blanket exception handler in the type converter turns the value into NULL while the INSERT reports success. Recorded on the adbcBridge side as an observed behaviour; the ArcadeDB team reproduced it on main, traced the root cause and opened the issue with a reproducer and a two-part fix proposal on 2026-09-21, the day it came up.

Why a client stack was pushing on the wire protocol

ADBC is Apache Arrow’s database connectivity API: one interface, columnar results, one driver per database. Most databases have no native ADBC driver, and ArcadeDB is one of them.

adbcBridge (adbcbridge.org, Apache-2.0) implements ADBC on top of any ODBC driver, so a database with an ODBC driver becomes reachable from pandas, Polars, DuckDB, Rust, .NET, Java and Go through Arrow. ArcadeDB has no ODBC driver either, and does not need one: its PostgreSQL protocol plugin lets the standard PostgreSQL ODBC driver, psqlodbc, connect. adbcBridge drives psqlodbc; psqlodbc drives ArcadeDB.

That is the route that has passed adbcBridge’s compatibility checks on Linux, macOS and Windows since August. The second route, Arrow’s own PostgreSQL ADBC driver straight to ArcadeDB, is what findings 1 and 2 unblocked. Both of them lean on the same thing: a client-server ArcadeDB speaking a protocol that other people’s tools already know how to speak.

What it looks like from Python

import adbcbridge, pandas

conn = adbcbridge.connect(
    uri="Driver={psqlodbcw.so};Server=127.0.0.1;Port=5432;"
        "Database=mydb;Uid=root;Pwd=...;BoolsAsChar=0;")

df = pandas.read_sql("SELECT * FROM Product WHERE price > 10", conn)

The same connection string works from Rust, C#, Java and Go through each language’s ADBC binding.

Driver= names the psqlodbc library as installed on Linux and macOS; on Windows the driver is registered as PostgreSQL Unicode(x64). BoolsAsChar=0 is a psqlodbc setting, not an ArcadeDB one: without it the ODBC driver reports every BOOLEAN as a five-character string.

Where it stands

Compatibility. ArcadeDB through psqlodbc is a passing read-only entry in adbcBridge’s matrix on Linux, macOS (Apple Silicon) and Windows. The timestamp behaviour in #8090 and the boolean fix from #6674 were re-verified on 26.9.1 on 2026-09-21 on Linux and macOS. The entry covers queries, parameters and catalog calls.

It is read-only by design: ArcadeDB has no CREATE TABLE, its DDL is CREATE DOCUMENT TYPE plus one CREATE PROPERTY per column, so the table-creating bulk-ingest path does not apply.

Two Arrow routes. adbcBridge over psqlodbc works against any released ArcadeDB. Arrow’s native PostgreSQL driver works against main after #7178 and #7188, with default options.

Every fix went upstream. None of the four findings is worked around on the client side. Each was fixed or filed in ArcadeDB, so every PostgreSQL client benefits, not only Arrow users.

Throughput, with the method

ArcadeDB 26.9 (PostgreSQL wire) through psqlodbc 16, in a 1 GB Docker container on the same laptop (Intel Core i9-13900HK, 14 cores / 20 threads, 31 GiB, Linux Mint 22.3, unixODBC 2.3.12). One table (id int32, val float64, txt utf8, dt date32); SELECT id, val, txt, dt of 100,000 rows drained into each language’s own Arrow record batches through adbcBridge; native delegation off, so every row travels over ODBC; median of 3 timings after a warmup, one database per run.

There is no ingest figure: ArcadeDB has no CREATE TABLE over the wire.

The five land between 327,000 and 417,000 rows/s, close enough to say what matters: the driver behaves the same whichever language loads it, and the differences are the bindings’ own.

Servers run locally, so the numbers reflect the ODBC driver plus the database rather than a network, and they move with whatever else is running on the host; read them as ratios, not absolutes. If you want numbers measured the way a database vendor measures them, ArcadeDB publishes its own on the benchmarks page; these are a client-stack measurement and answer a different question.

Harness: bench/langbench.sh. Published rows: bench/LANGUAGE_BENCHMARKS.md. The ArcadeDB fixture is the arcadedb service in tests/compat/docker-compose.yml.

Links

The two ArcadeDB notes on adbcbridge.org: ArcadeDB fixed the pg_type bootstrap within a day and A timestamp that stores NULL and says it worked, and a boolean note that went stale, which carries the 26.9.1 retest and the bound-parameter case.

The compatibility matrix: adbcbridge.org. The repository: github.com/singhpratech/adbcbridge; questions and defects go to its issues.

Published with the author’s permission. The findings above were reported through ArcadeDB’s public issue tracker, and #7815 was contributed as a pull request by the adbcBridge project.

That last part is the detail worth sitting with. The Toolbox (16.5k stars on GitHub, Apache 2.0, maintained by Google) is already the MCP server plenty of teams point at PostgreSQL, BigQuery, Snowflake, Spanner, and Neo4j. ArcadeDB is now in that same list. A team already running the Toolbox in front of Neo4j or Postgres doesn’t need to learn a new integration pattern to add ArcadeDB: it’s the same source-and-tool YAML shape, the same auth model, the same observability pipeline. That’s real distribution, not a blog-post announcement.

What the Toolbox actually does

MCP Toolbox for Databases solves a problem that shows up the moment you connect more than one agent to more than one database: every hand-rolled integration reinvents connection pooling, credential handling, and query safety. The Toolbox centralizes that. You describe a source (a database connection) and one or more tools (a named, scoped operation an agent can call) in YAML, and the Toolbox exposes those tools over MCP. Support for Google Sign-In and generic OIDC, Model Armor request screening, telemetry export, and read-only tool modes all come from the Toolbox itself, so an ArcadeDB integration inherits them for free.

Configuring the ArcadeDB source

A source points the Toolbox at a running ArcadeDB server over the Bolt protocol:

kind: source
name: my-arcadedb-source
type: arcadedb
uri: bolt://localhost:7687
user: root
password: ${PASSWORD}
database: "mydb"

This assumes ArcadeDB running as a server with Bolt enabled, since the Toolbox connects to it the same way a Neo4j driver would. ${PASSWORD} is environment-variable substitution: the Toolbox recommends it over hardcoding credentials in the YAML, which matters the moment this config file ends up in a repository.

The two tools

With the source defined, the integration exposes exactly two tools.

arcadedb-execute-cypher runs Cypher against the source:

kind: tool
name: query_arcadedb
type: arcadedb-execute-cypher
source: my-arcadedb-source
readOnly: true
description: |
  Execute Cypher against ArcadeDB in read-only mode.
  Example:
  {{
      "cypher": "MATCH (n) RETURN count(n)"
  }}

arcadedb-execute-sql runs ArcadeDB SQL, which is where the multi-model part of ArcadeDB shows up: the same tool reaches graph and document data in one query, since SQL and Cypher operate against the same underlying records.

kind: tool
name: query_arcadedb_sql
type: arcadedb-execute-sql
source: my-arcadedb-source
description: |
  Execute SQL against ArcadeDB.
  Example:
  {{
      "sql": "SELECT FROM Person WHERE name = :name LIMIT 5",
      "params": {
        "name": "Ada"
      },
      "dry_run": false
  }}

Both tools accept readOnly to block write statements and a per-call dry_run to validate a query without running it. Set readOnly: true unless the agent genuinely needs to write, the same way you’d scope any credential you hand to an LLM.

Not a replacement for the built-in MCP server

ArcadeDB has had its own built-in MCP server since v26.3.1, running inside the database engine with five tools covering schema discovery, querying across every supported query language, and writes with per-operation permission flags. That path is still the fastest way to connect a single AI client directly to a single ArcadeDB instance: nothing to deploy, native authentication, zero extra hops.

The Toolbox integration solves a different problem. It’s for teams that already standardized on the Toolbox as their agent-to-database layer, often because they’re already using it for other databases in the same stack. For them, ArcadeDB showing up as a source type means one less custom integration to maintain, and it means ArcadeDB gets evaluated in the same breath as PostgreSQL, Spanner, and Neo4j rather than needing a separate pitch for why an AI agent should be allowed to talk to it at all.

Try it

The full integration docs, including the generic prebuilt-config workflow the Toolbox uses for every source type, are at mcp-toolbox.dev/integrations/arcadedb. The Toolbox itself is on GitHub at googleapis/mcp-toolbox.