Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
What the Helix Cloud architecture is optimized for, and where another system may fit better
| Area | Details |
|---|---|
| Durable storage | All data persists in object storage. No risk of data loss from local disk failure. Storage capacity scales independently of compute. |
| Read scalability | Readers auto-scale horizontally. Doubling readers doubles read throughput with no coordination overhead. |
| Serializable transactions | Every query runs against a stable snapshot with ACID semantics by default. |
| Mixed graph, vector, and text workloads | Graph traversals, vector search, and full-text search execute in the same transaction, against the same snapshot. No need to stitch together separate systems for those workloads. |
| Cost efficiency at scale | Object storage is significantly cheaper per GB than local SSDs or in-memory stores. Large datasets remain affordable. |
| Operational simplicity | Single writer eliminates distributed consensus. No leader election, no split-brain, no quorum management. |
| Area | Details |
|---|---|
| Sub-millisecond reads | Cache hits are fast, but cold reads require an object storage round trip. Workloads that require guaranteed sub-millisecond latency on every read are better served by in-memory databases. |
| Ultra-low write latency | Writes incur object storage latency for durability. Write throughput is high, but individual write latency has a floor set by object storage round-trip time. |
| Exhaustive vector recall | Vector search is approximate (ANN). Applications that require 100% exact nearest neighbor results should use brute-force search on smaller datasets. |
Was this page helpful?
