ArcadeDB is an open-source multi-model database that bundles graph, document, key-value, and search capabilities in one system. It is relevant for GraphRAG-style architectures when multiple data models are intended to work together deliberately. Its practical value lies in a compact platform for combined semantic, document-centric, and relational access patt…
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
ArcadeDB is an open-source multi-model database that combines graph, document, key-value, search, and vector capabilities in one engine.
ArcadeDB was developed by Arcade Data Ltd. as an Apache-2.0 licensed open-source database for applications that need more than one data shape at once. Its concrete counterpoint is polyglot persistence: instead of splitting graph, document, key-value, search, and vector data across separate systems, ArcadeDB brings those models into one engine; the GraphRAG documentation shows a later use for combined retrieval.
Think of ArcadeDB as a shared data core with several entry and exit paths. The same content lives in one core but is read as a graph, document, key-value record, full-text match, or vector depending on the access path. A query can therefore traverse, search text, and check similarity without moving between specialized databases or syncing duplicate copies.
One shared core serves several data shapes instead of distributing them across different products.
Graph nodes, documents, and vectors are handled as part of the same engine model.
The same data set can be addressed through SQL, Cypher, Gremlin, GraphQL, or MongoDB depending on the task.
Traversal, full-text, and similarity can work together in one query to gather connected context.
Separate specialized databases appear when each data model needs its own system; ArcadeDB aims to reduce those integration costs.
ArcadeDB is useful when an application needs relationships, documents, and semantic search to work together, for example in knowledge graphs, GraphRAG, or mixed-model prototypes. The benefit is fewer system boundaries and fewer duplicate copies; the trade-off is that modeling, index selection, and operations must be tuned for several access patterns. For strictly separated workloads, a specialized system may be simpler.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.