> ## Documentation Index > Fetch the complete documentation index at: https://docs.helix-db.com/llms.txt > Use this file to discover all available pages before exploring further. # Architecture export const architectureDiagram = [" │", " │", " ╔════════════════════════════▼══════════════════════════╗", " ║ Gateway ║░", " ╚═══╦═══════════════╤═══════════════╤═══════════════╤═══╝░", " ░░║░░░░░░░░░░░░░░░│░░░░░░░░░░░░░░░│░░░░░░░░░░░░░░░¦░░░░░", " ║ │ │ │", " ║ │ │ │", " ╔═════╩═════╗ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐", " ║ Writer ║ │ Reader │ │ Reader │ │ ... │", " ║ ┏━━━━━━━┓ ║ │ ┌───────┐ │ │ ┌───────┐ │ │ │", " ║ ┃ Cache ┃ ║ │ │ Cache │ │ │ │ Cache │ │ │ ... │", " ║ ┃ SSD ┃ ║ │ │ SSD │ │ │ │ SSD │ │ │ │", " ║ ┗━━━━━━━┛ ║ │ └───────┘ │ │ └───────┘ │ │ │", " ╚═════╦═════╝ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘", " ║ │ │ │", " ║ │ │ │", " ║ │ │ │", "╔═════════╩═══════════════╧═══════════════╧═══════════════╧═════════╗", "║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║", "║ ░░░░░░░░░░░░░░░░░░░░░░░░ Object Storage ░░░░░░░░░░░░░░░░░░░░░░░ ║", "║ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║", "╚═══════════════════════════════════════════════════════════════════╝"].join("\n"); export const EnterpriseDiagram = ({diagram}) => { return 
        {diagram}
; }; > For the complete documentation index optimized for AI agents, see [llms.txt](/llms.txt). Helix Cloud runs as a single writer node and multiple reader nodes behind a routing gateway. Reads scale horizontally. Writes are serialized through a dedicated writer process to maintain a simple consistency model. Helix Cloud is a fundamentally different architecture and database compared to the opensource v1 version of HelixDB. That version used LMDB which was limited to sequential writes and could only handle a relatively small amount of data. Helix Cloud uses a new LSM based storage engine backed by object storage that can handle concurrent writes to the writer node and allows for virtually unlimited data storage. ## Gateway The gateway is the entry point for all client traffic. It authenticates each request via Bearer token, accepts the inline query payload, and routes it: mutations always go to the writer, read-only queries are distributed across the readers and the writer. For high availability, deploy at least three gateway instances per cluster. Smaller fleets work for non-HA or test workloads but are not recommended for production. ## Writer A single writer process handles all mutations. The writer supports concurrent write transactions through MVCC (multi-version concurrency control), allowing multiple writes to execute in parallel without blocking each other. Serializing the commit path through one process eliminates distributed coordination and simplifies the consistency model. The writer batches mutations for throughput and persists them durably to object storage before acknowledging. The writer also serves read-only queries. It maintains its own SSD and in-memory cache, giving it the most up-to-date view of the data. Reads routed to the writer see committed writes immediately, with no snapshot refresh delay. ## Readers Readers serve all read-only queries. They are stateless with respect to writes and can be added or removed without coordination. Each reader maintains a local SSD and in-memory cache populated from object storage. Reader scaling is automatic. As query load increases, new readers are provisioned. As load decreases, excess readers are removed. This keeps cost proportional to actual query volume. ## Object Storage Object storage is the durable system of record. All graph data, vector indexes, text index artifacts, and metadata persist here. No data lives exclusively on local disk. This means the system can recover from a full cache loss by reading from object storage, and storage capacity is effectively unbounded. ## Cache Hierarchy Each process (writer and readers) maintains local cache tiers for the data and indexes it serves. * **In-memory cache.** Fastest access. Holds the most frequently accessed graph data, vector search state, and hot text-search generations. Bounded by available RAM. * **SSD cache.** Larger capacity, lower cost per byte. Holds warm graph data, vector data, and reusable text-search artifacts. Reads from SSD are significantly faster than reads from object storage. Graph, vector, and text workloads use specialized cache paths so hot working sets do not fully contend with one another. On cold start, caches warm progressively as queries execute; for predictable latency from the first query, caches (including text index generations) can be pre-warmed. ## Read Path 1. A read request arrives at the gateway and is routed to a reader or the writer. 2. The reader resolves a consistent snapshot from object storage metadata. 3. Data is read from the in-memory cache, SSD cache, or object storage (in that order). 4. The query executes against the snapshot and returns results. Cache misses transparently fall through to object storage. The same query produces the same result regardless of cache state; caching affects latency, not correctness. ## Write Path 1. A write request arrives at the gateway and is routed to the writer. 2. The writer executes the mutation within a serializable transaction. Multiple write transactions execute concurrently via MVCC; conflicts are resolved at commit time. 3. The mutation is batched and persisted durably to object storage. 4. Once durable, the write is acknowledged to the client. 5. Readers observe the new data on their next snapshot refresh. ## Next Steps Nodes, edges, properties, and the labeled multigraph model. Secondary, vector, and text indexes over the property graph. Traversal DSL, dynamic queries, and transactions. Consistency, durability, and isolation under this architecture.