Key/Value
The key/value model is the simplest data model: every value is reachable through a single identifier (the key). ArcadeDB supports the key/value pattern natively without sacrificing the richer features of the multi-model engine — values can be primitive types, full documents, or even graph elements.
How Keys Work in ArcadeDB
Every record stored in ArcadeDB is automatically addressable by its Record ID (RID), a compact identifier of the form #bucket:offset.
The RID provides O(1) direct access to any record, which means the entire database functions as a high-performance key/value store — no separate engine, no extra indexes required.
In addition to RIDs, you can layer your own keys on top:
-
Indexed keys — create a unique LSM-Tree index on any property to look up records by an arbitrary identifier such as
userId,sku, oremail. -
Bucket-based keys — group records into buckets and use the bucket as a key/value namespace where records are inserted and retrieved by RID without requiring a type schema.
-
Composite keys — create indexes spanning multiple properties when the natural key is not a single value (for example,
(tenantId, accountId)).
HTTP Key/Value Patterns
The most typical use cases of the Key/Value model are exposed directly through the HTTP API:
| Operation | HTTP Call | Effect |
|---|---|---|
Store |
|
Save the value as the payload of the call |
Read |
|
Return the value as the response payload |
Delete |
|
Remove the value identified by the key |
This makes ArcadeDB usable as a drop-in key/value backend for caches, session stores, configuration stores, or any pattern where direct addressing by identifier is the primary access mode.
Comparison with Other Models
| Relational Model | Key/Value Model | ArcadeDB Key/Value Model |
|---|---|---|
Table |
Bucket |
|
Row |
Key/Value pair |
Document |
Column |
not available |
Document field or Vertex/Edge property |
Relationship |
not available |
Why ArcadeDB for Key/Value
Most key/value stores treat the value as opaque — a blob of bytes the database doesn’t understand. ArcadeDB treats every value as a structured record:
-
Rich values — values can be documents, vertices, or edges with typed properties, not just byte arrays.
-
Queryable — the same record retrievable by RID is also queryable with SQL, Cypher, Gremlin, and other languages, without re-indexing or duplicating data.
-
Transactional — key/value writes participate in full ACID transactions alongside graph and document operations.
-
Persistent — LSM-Tree storage with automatic compaction ensures durability and efficient disk usage at scale.
-
Multi-protocol — access the same data through HTTP, the Redis wire protocol, the Java API, or any other supported interface.
Further Reading
-
Record ID (RID) — how RIDs work and how to use them as primary keys
-
Buckets — physical storage units that double as key/value namespaces
-
HTTP API — REST endpoints for POST/GET/DELETE on records
-
Redis Wire Protocol — speak the Redis protocol against ArcadeDB