ArcadeDB: One Database Engine, Seven Data Models, and a Lot of Compatibility Claims

The Problem ArcadeDB Solves: Too Many Databases, One Cluster

Most applications end up running several databases: a graph database for relationships, a document store for flexible records, a time-series database for metrics, and a vector store for embeddings. Operating all of them means multiple deployment pipelines, multiple backup strategies, and multiple query languages for your developers to learn. ArcadeDB attacks this problem with a single server that exposes all of these models through one engine. It is a conceptual fork of OrientDB, created by the same founder after SAP acquired OrientDB. The pitch is that you can replace several specialized systems with one DBMS that speaks their protocols. That is an ambitious claim, and the rest of this review looks at how the project backs it up.

Under the Hood: A New Engine with Old SQL Roots

ArcadeDB is written from scratch, but it reuses OrientDB's SQL engine, heavily modified, plus some utility classes. The engine is written in what the README calls Low Level Java, meaning Java 21+ but using only low-level APIs to reduce garbage collector pressure. This is a design choice aimed at performance and predictable latency. The database is fully transactional with ACID support, and it stores records with links rather than joins for its graph model. The documentation mentions native graph engine capabilities, full-text indexing, and geospatial queries. The architecture is a single storage engine that presents different query interfaces on top. That is different from a federated system that queries separate backends. The trade-off is that you get consistency across models, but you also get one engine's limitations applied to all of them.

Getting Started: Docker, Java, and the 5-Minute Server

The README promises a five-minute setup using Docker. The command is straightforward: docker run --rm ... (the README truncates the full command, but the pattern is standard for pulling the arcadedata/arcadedb image and exposing ports). The project also runs as an embedded database from any JVM language, and there is a Python binding called arcadedb-embedded-python. For remote access, you can use HTTP/JSON, a Postgres driver, a Redis driver, or a MongoDB driver. The Postgres driver uses the actual Postgres wire protocol, which is notable because it means you can connect with standard Postgres clients. The Redis and MongoDB drivers are explicitly partial: the README says only a subset of operations are implemented. That is a critical constraint for anyone expecting drop-in replacement.

Multiple Query Languages: More Than Just a Party Trick

ArcadeDB supports SQL, Cypher, Gremlin, GraphQL, and MongoDB Query Language. The SQL is derived from OrientDB SQL, so it has its own dialect. Cypher compatibility is with Open Cypher, which is the open version of Neo4j's query language, not the proprietary full version. Gremlin is supported via Apache TinkerPop 3.7.x. GraphQL is listed as a language, which is unusual for a database. The README also mentions a built-in MCP server for AI assistant integration, which is a modern touch. The practical implication is that you can write a graph traversal in Cypher, a document query in MongoDB syntax, and a time-series query in PromQL, all against the same data. But each language has its own compatibility surface, and the MongoDB and Redis subsets are not fully documented in the README. You will need to check the docs for each operation you rely on.

Vector Embeddings and Time-Series: The Modern Additions

Vector embeddings are a first-class model in ArcadeDB, which is important for AI workloads like recommendation engines and Graph RAG. The use cases repository includes examples for recommendation engines that combine graph traversal, vector similarity, and time-series. Time-series support includes columnar storage with Gorilla and Delta-of-Delta compression, which are well-known compression techniques for time-series data. It ingests data via InfluxDB Line Protocol and Prometheus remote_write/read, and it supports PromQL queries with Grafana integration. This is a serious feature set that goes beyond simple key-value stores. However, the README does not provide details on vector index types or similarity functions. If you need specific vector operations like cosine similarity or approximate nearest neighbor search, you will have to dig into the documentation to confirm they exist and how they perform.

Graph Algorithms and Materialized Views: Built-In Power or Overhead?

ArcadeDB ships with 70+ built-in graph algorithms, covering pathfinding, centrality, community detection, link prediction, and graph embeddings. That is a substantial library, and it means you do not need to export your graph to a separate analytics tool. The engine also supports materialized views, which are pre-computed query results that are automatically maintained. That is useful for dashboards and real-time analytics, as the use cases mention social network analytics with materialized view dashboards. Parallel query execution across CPU cores is another performance feature. The trade-off is that these features add complexity to the server. Materialized views need to be refreshed on writes, and graph algorithms can be memory-intensive on large datasets. The README does not specify how the algorithms are implemented or whether they run in-memory or on-disk, so you should benchmark with your own data.

Limitations and Failure Modes: Where the Multi-Model Promise Strains

The most obvious limitation is the partial implementation of MongoDB and Redis protocols. If your application relies on MongoDB features like aggregation pipelines or change streams, ArcadeDB may not support them. Similarly, Redis operations beyond basic get/set might be missing. The README explicitly says only a subset of operations are implemented, but it does not list which ones. That is a discovery burden on the adopter. Another limitation is the Java-centric nature. While there is a Python binding, the core is Java 21+, and embedded use requires a JVM. If your stack is entirely Node.js or Go, you would be using the network protocols, which brings back the compatibility issue. The project also has a very broad feature surface, which can mean more bugs and slower fixes. The recent release cadence (26.8.1 in August 2026, 26.7.3 in July, 26.7.2 in July) shows active maintenance, but you should still verify that your critical features work in your environment.

Alternatives: How ArcadeDB Compares to Specialized Engines

The obvious alternative is to use Neo4j for graph, MongoDB for documents, and InfluxDB for time-series. Each of those is a specialized engine with deep feature sets and mature ecosystems. Neo4j has a large community and extensive Cypher support, but it is not multi-model. MongoDB has a rich aggregation framework and change streams, but it is not a graph database. InfluxDB is purpose-built for time-series with high write throughput, but it does not handle graph or document workloads. ArcadeDB's approach is to give you one engine that does all of this, with the trade-off that each protocol is a subset. Another alternative is to use a multi-model database like ArangoDB, which also supports document, graph, and key-value models, but it does not have the same breadth of protocol compatibility. ArcadeDB's unique selling point is the protocol-level compatibility, not just the data models. The Postgres wire protocol support is particularly interesting because it lets you use existing Postgres tools and drivers.

Editorial conclusion

Adopt ArcadeDB if you need one engine for graph, document, and time-series workloads and you can tolerate partial protocol compatibility. Do not adopt it if you require full MongoDB or Redis feature parity, or if your team is not comfortable with Java-centric operations. Before committing, verify that the specific MongoDB operations, Redis commands, and Cypher features your application uses are implemented, and test the Postgres wire protocol against your existing drivers. The project is actively maintained with recent releases, but the breadth of models means you must validate each one independently.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes