> ## Documentation Index
> Fetch the complete documentation index at: https://helix-isolate-failing-index-entities.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Guarantees

> Atomicity, isolation, durability, index activation, and read-after-write behavior

<div className="flex flex-wrap gap-2"><Badge color="gray" size="sm">Reference</Badge></div>

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](/database/helix-db/query-guides/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](/database/helix-db/query-guides/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](mailto:founders@helix-db.com) for current redundancy and SLA
terms instead of assuming a topology from the SDK contract.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.