Guarantees

HelixDB executes each query request as one transaction over a committed snapshot.

​

Atomicity

All mutations in one write batch commit together or roll back. A failed operation does not leave earlier mutations from the same request committed.

​

Consistency

Constraints such as unique indexed values, property encodings, vector dimensions, and text index value requirements are checked before the relevant write or index generation becomes active.

​

Isolation

Transactions use serializable snapshot isolation:

• A request reads graph and index state from one committed snapshot.
• A write request reads its own mutations before commit.
• Conflicting writes are detected at commit; the request fails instead of committing against stale transactional state.
• Secondary, vector, and text lookups participate in the same request transaction. A write request that searches a vector or text index conflicts with any concurrent write to that index, including work not yet published into it, and with the index worker publishing that work. Both fail with a retryable transaction_conflict; under a sustained publication backlog, searching writes may need several retries. See Search consistency.

​

Durability

Canonical data is persisted by the selected storage source. In Cloud, local memory and disk caches are performance layers; object storage is canonical. Server clients can explicitly set shouldAwaitDurability(true) / should_await_durability(true) when the acknowledgement must wait for the configured durability boundary, or false when the application accepts an earlier acknowledgement. Embedded mode rejects this server-only option.

​

Index activation

Index creation and deletion use durable lifecycle operations:

• A build scans existing entities. A secondary-index build then catches up concurrent mutations; vector and text writes made during a build are queued and published after activation.
• A constructing generation is hidden from queries.
• Validation completes before one atomic activation step.
• A blocked or aborted generation never becomes partially queryable.

​

Readers and read-after-write

The writer can serve a newly committed state immediately. A reader observes it after refreshing to a snapshot that contains the commit, so a request routed to a reader may temporarily lag. Vector and text searches include committed writes that the index worker has not published yet, unless a read opts into eventual search consistency, so they follow the same rules. Use a writer-only server request when a separate request requires read-after-write: Call writerOnly() on the TypeScript request builder, writer_only() on the Python QueryBuilder (or pass writer_only=True to Client.execute), or pass helix.WriterOnly() to Go Client.Exec before sending the read. Embedded writer handles execute against their local writer. Embedded reader handles are read-only and refresh according to the underlying reader lifecycle.

​

Cloud availability

Cloud availability and recovery depend on the purchased deployment topology. Contact founders@helix-db.com for current redundancy and SLA terms instead of assuming a topology from the SDK contract.