Multi-Model Architecture
ArcadeDB is a multi-model database that natively supports documents, graphs, key-value, time series, full-text search, and vector embeddings within a single engine. All models share the same storage layer, the same transaction manager, and the same query infrastructure. This design eliminates the need for polyglot persistence — the practice of running separate specialized databases for different data models — and the operational complexity that comes with it.
ArcadeDB is a true Multi-Model DBMS, combining all the features of the supported models into one core. This is not just a thin layer of interfaces over a single underlying engine, as is common in other "multi-model" databases. The ArcadeDB engine itself was built from the ground up to support every model, which is why it can deliver speed and scalability that bolt-on approaches cannot.
Why Multi-Model Matters
Traditional architectures often pair a relational database with a graph database, a document store, a time series backend, and a vector index. Each system brings its own deployment, its own backup strategy, its own security model, and its own failure modes. Keeping data consistent across these systems requires ETL pipelines, message queues, or change-data-capture infrastructure that adds latency and introduces synchronization bugs.
ArcadeDB collapses this stack into one process. A single ACID transaction can create a document, connect it as a vertex in a graph, and index its embedding for vector similarity — atomically. There is no replication lag between models because there is no replication; the data exists once.
The Latency Problem with Multiple Databases
With polyglot persistence, a single user request often triggers a chain of sequential calls across different databases. Each call adds network latency, serialization overhead, and wait time. The total response time is the sum of all calls.
The numbers below match the animation:
| Polyglot Persistence (Sequential Calls) | Database | Latency |
|---|---|---|
Your App → MySQL |
Relational |
~15ms |
Wait… → MongoDB |
Document |
~20ms |
Wait… → Neo4j |
Graph |
~12ms |
Total: ~47ms+ (sum of all calls + serialization overhead) |
||
| ArcadeDB (Single Call) | Engine | Latency |
|---|---|---|
Your App → ArcadeDB (graph + doc + search in one query) |
Multi-Model |
~5ms |
Total: ~5ms (one call, zero chaining, no serialization) |
||
With a multi-model database, your application makes a single call that can query graphs, documents, and full-text search at the same time. No chaining, no waiting, no redundant serialization. The result? Dramatically lower latency and simpler application code.
ArcadeDB natively supports six data models: Graph, Document, Key-Value, Full-Text Search, Vector, and Time-Series — all within a single, embeddable database engine.
Supported Data Models
Document Model
The data in this model is stored inside documents. A document is a set of key/value pairs (also referred to as fields or properties), where the key allows access to its value. Values can hold primitive data types, embedded documents, or arrays of other values. Documents are not typically forced to have a schema, which can be advantageous because they remain flexible and easy to modify. Documents are stored in collections, enabling developers to group data as they decide. ArcadeDB uses the concepts of "Types" and "Buckets" as its form of "collections" for grouping documents.
ArcadeDB’s document model also adds the concept of a "Relationship" between documents. You can decide whether to embed documents or link to them directly. When you fetch a document, all the links are automatically resolved by ArcadeDB. This is a major difference compared to other document databases, like MongoDB or CouchDB, where the developer must handle every relationship between documents themselves.
Types can operate in schema-full mode (all properties declared), schema-less mode (no schema constraints), or schema-hybrid mode where some properties are enforced while others remain free-form. Document types support inheritance, allowing a subtype to extend a parent type and inherit its properties.
| Relational Model | Document Model | ArcadeDB Document Model |
|---|---|---|
Table |
Collection |
|
Row |
Document |
Document |
Column |
Key/value pair |
Document property |
Relationship |
not available |
Graph Model
A graph represents a network-like structure consisting of Vertices (also known as Nodes) interconnected by Edges (also known as Arcs). ArcadeDB’s graph model is represented by the concept of a property graph, which defines the following:
-
Vertex - an entity that can be linked with other vertices and has the following mandatory properties:
-
unique identifier
-
set of incoming edges
-
set of outgoing edges
-
label that defines the type of vertex
-
-
Edge - an entity that links two vertices and has the following mandatory properties:
-
unique identifier
-
link to an incoming vertex (also known as head)
-
link to an outgoing vertex (also known as tail)
-
label that defines the type of connection/relationship between head and tail vertex
-
In addition to mandatory properties, each vertex or edge can also hold a set of custom properties, which makes vertices and edges look similar to documents. Edges are first-class citizens stored in their own types — not join tables or adjacency lists bolted onto a relational schema. ArcadeDB supports two kinds of edges: lightweight edges for simple relationships that carry no properties, and regular edges for relationships that need their own attributes such as weight, timestamp, or label. Graph traversal operates at O(1) complexity per hop through index-free adjacency.
| Relational Model | Graph Model | ArcadeDB Graph Model |
|---|---|---|
Table |
Vertex and Edge Types |
Type |
Row |
Vertex |
Vertex |
Column |
Vertex and Edge property |
Vertex and Edge property |
Relationship |
Edge |
Edge |
Key/Value Model
This is the simplest model: everything in the database can be reached by a key, where the values can be simple or complex types. ArcadeDB supports documents and graph elements as values, providing a richer model than typical key/value stores.
For the full description, comparison table, and HTTP usage patterns, see the dedicated Key/Value page.
Search-Engine Model
The search engine model is based on a full-text variant of the LSM-Tree index. To index each word, the necessary tokenization is performed by the Apache Lucene library. A full-text index is created just like any other index in ArcadeDB and participates in the same transaction as the rest of the database.
Time-Series Model
ArcadeDB includes a native time-series engine designed for high-throughput ingestion and fast analytical queries over timestamped data. The Time-Series model is integrated directly into the multi-model core — the same database that stores graphs, documents, and key/value pairs can store and query billions of time-stamped samples with specialized columnar compression, SIMD-vectorized aggregation, and automatic lifecycle management.
Key capabilities:
-
Columnar storage with Gorilla, Delta-of-Delta, Simple-8b, and Dictionary compression — as low as 0.4 bytes per sample
-
Shard-per-core parallelism with lock-free writes
-
InfluxDB Line Protocol ingestion for compatibility with Telegraf, Grafana Agent, and hundreds of collection agents
-
Prometheus remote_write / remote_read protocol for drop-in Prometheus backend usage
-
PromQL query language with native parser and HTTP-compatible API endpoints
-
SQL analytical functions —
ts.timeBucket,ts.rate,ts.percentile,ts.interpolate, and more -
Continuous aggregates, retention policies, and downsampling tiers for automatic data lifecycle
-
Grafana integration via DataFrame-compatible endpoints
-
Studio TimeSeries Explorer with query, schema inspection, ingestion docs, and PromQL tabs
For the full reference, including DDL syntax, ingestion methods, SQL functions, PromQL support, and Grafana integration, see Time Series.
Vector Model
ArcadeDB provides a high-performance vector indexing solution using the LSMVectorIndex, which is built on the JVector library.
It implements both the hierarchical navigable small world (HNSW) algorithm and the Vamana (DiskANN) algorithm for efficient approximate nearest neighbor (ANN) search on multi-dimensional vector data.
Vector indexes participate in ACID transactions, persist on disk with automatic compaction, and integrate directly into SQL queries through vectorNeighbors().
For SQL and Java examples, supported similarity functions, configuration parameters, quantization, and tuning advice, see the dedicated Vector page.
Unified Query Layer
All data models are accessible through multiple query languages that operate on the same underlying records:
-
SQL — The primary query language, extended with graph traversal, time series aggregation, and vector similarity functions
-
Cypher — Pattern-matching queries for graph traversal
-
Gremlin — Imperative graph traversal language (Apache TinkerPop)
-
GraphQL — Schema-driven queries over HTTP
-
MongoDB Query Language — Document-oriented queries for migration compatibility
-
Redis Protocol — Key-value operations over the Redis wire protocol
Because all languages read from and write to the same storage, a record created through SQL is immediately visible to a Gremlin traversal, and an edge created through Cypher can be queried with GraphQL.
Type Inheritance Across Models
ArcadeDB types follow an object-oriented inheritance model. A type can extend another type, inheriting all of its properties, indexes, and constraints. This applies uniformly to document types, vertex types, and edge types.
For example, a Person vertex type can serve as the parent for both Employee and Customer types.
A query against Person automatically includes records from all subtypes, while a query against Employee returns only employees.
This polymorphic behavior works identically regardless of which query language is used.
Schema Flexibility
ArcadeDB supports three schema modes that can be mixed within the same database:
-
Schema-full — Every property is declared with a type and optional constraints. Attempts to store undeclared properties are rejected.
-
Schema-less — No schema is defined. Records accept arbitrary properties with no validation.
-
Schema-hybrid — Some properties are declared and enforced, while additional properties can be added freely.
This flexibility allows different types in the same database to use different schema strategies.
A Transaction type might enforce strict schema-full validation, while a Metadata type might operate schema-less to accommodate evolving requirements.
Cross-Model Queries
The most powerful consequence of the multi-model architecture is the ability to combine models in a single query. A SQL statement can traverse graph edges, filter on document properties, aggregate time series data, and rank results by vector similarity — all in one pass, within one transaction.
SELECT FROM (
MATCH {type: User, as: u}-Follows->{type: User, as: f}
RETURN f
) WHERE vectorCosineSimilarity(f.embedding, ?) > 0.8This query traverses the Follows graph to find users connected to a starting set, then filters the results to only those whose embedding vectors are semantically similar to a target.
No ETL, no cross-database joins, no eventual consistency — the graph traversal and the vector comparison execute against the same records in the same transaction.