One database, six personalities, zero patience for your stack sprawl
ArcadeDB crams graph, document, key-value, time-series, search, and vector models into a single engine so you can stop duct-taping databases together.

What it does
ArcadeDB is a multi-model database that handles graph (Cypher, Gremlin), document (MongoDB-compatible), key-value (Redis wire protocol), full-text search, time-series, and vector embeddings—all inside one transactional engine. It speaks SQL (OrientDB-derived), GraphQL, MongoDB queries, and even implements the Postgres wire protocol for remote access. You can run it embedded in JVM apps, from Python, via HTTP/JSON, or through familiar drivers.
The interesting bit
The project is a clean-slate rewrite by OrientDB’s original founder after SAP acquired his first company. The README brags about “Low Level Java”—Java 21+ restricted to low-level APIs for “mechanical sympathy” and reduced GC pressure. Whether that delivers the claimed “millions of records per second on common hardware” is left to your own benchmarking; the sources don’t provide numbers.
Key highlights
- 70+ built-in graph algorithms (pathfinding, centrality, community detection) available without external libraries
- Time-series storage with Gorilla/Delta-of-Delta compression, InfluxDB Line Protocol and PromQL support
- Materialized views with automatic maintenance
- Built-in MCP server for LLM/AI assistant integration, plus a beta AI assistant in Studio
- Modular packaging: four release variants from “full” down to “base” (core engine only), plus a custom package builder
- Geospatial indexing with native
geo.*SQL functions
Caveats
- Redis and MongoDB drivers implement “only a subset of the operations”—check your specific workloads before migrating
- Java 21 is the mainline; Java 17 support lives on a separate branch via GitHub Packages, not Maven Central
- The “Alien Technology” marketing phrase in the README is doing a lot of heavy lifting
Verdict
Worth a look if you’re tired of maintaining separate Neo4j, MongoDB, Redis, and InfluxDB instances for a medium-complexity application. Probably overkill if you only need one data model and already have that database tuned.