> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lancedb.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Consistency

> Understand when readers see changes and choose the freshness your application needs.

**Applies to:** Embedded ✅, Enterprise ✅

## Table snapshots and freshness

Each table read uses one committed version of the data. **Freshness** describes
whether that version includes recent writes. For example, after another
application appends records, an already-open table handle can still read the
version from before the append.

For example, a dashboard may need the latest updates, while an experiment may
need to keep reading a specific table version. Use read freshness settings for the dashboard and an explicit table version
for the experiment.

## Visibility of writes

In **LanceDB Embedded**, a table handle sees its own committed writes. By default, it does
not automatically check for changes made through other handles or processes.
Use a read consistency interval or `checkout_latest()` to pick up those changes.

In **LanceDB Enterprise**, readers use the service's configured freshness
policy.
A connection can request fresher data. When a read must include a completed
write, use a zero interval or call `checkout_latest()` after the write, with a
client and server that support these freshness controls.

## Configure read freshness

Set `read_consistency_interval` when connecting. This controls when reads
pick up newer table versions; it does not change how writes commit.

| Setting | Embedded | Enterprise |
| - | - | - |
| **Unset** | Keep the open table version until explicitly refreshed or changed by that handle. | Use the service's configured freshness policy. |
| **Zero** | Check for the latest committed version on every read. | Request the latest committed version on every read. |
| **Non-zero interval** | Check for updates on a read once the interval since the last check has elapsed. | Request data no older than the interval allows; the service may return fresher data. |

`checkout_latest()` explicitly refreshes an Embedded table handle. On Enterprise it
asks subsequent reads on that handle to reflect data at least as recent as the
refresh request. To read a fixed historical version instead, use
[table versioning](https://docs.lancedb.com/enterprise/v1-12-0/management/table.md#versioning).

> [accordion] Complete Python example: compare two readers
>
> Install the Python SDK with `pip install lancedb`, then save this as
> `consistency.py` and run `python consistency.py`. It creates a temporary local
> database and removes it when finished. No Enterprise connection is needed.
>
> ```python consistency.py icon="python" theme={"theme":{"light":"vitesse-light","dark":"catppuccin-mocha"}}
> from datetime import timedelta
>
> import lancedb
>
> writer = lancedb.connect(uri)
> table = writer.create_table("documents", [{"id": 1, "text": "first"}])
>
> default_reader = lancedb.connect(uri).open_table("documents")
> latest_reader = lancedb.connect(
>     uri, read_consistency_interval=timedelta(0)
> ).open_table("documents")
>
> table.add([{"id": 2, "text": "second"}])
>
> default_count = default_reader.count_rows()
> latest_count = latest_reader.count_rows()
> print(f"Default reader: {default_count} rows")  # 1
> print(f"Zero-interval reader: {latest_count} rows")  # 2
>
> default_reader.checkout_latest()
> refreshed_count = default_reader.count_rows()
> print(f"After explicit refresh: {refreshed_count} rows")  # 2
> ```
>
> The default reader sees one row until refreshed. The reader with a zero
> interval sees the new row on its next read.

## Choose a freshness interval

* **Reads that must include recent writes:** use a zero interval. Checking more
  frequently can increase read latency and storage requests.
* **Dashboards with an acceptable delay:** choose an interval within that delay
  budget, then measure the effect on latency and cost.
* **Reproducible experiments:** read an explicit table version and retain it for
  as long as the experiment needs it.

Choose the interval based on the delay your application can tolerate between
a write completing and a reader seeing it.

## Learn more

* [Connect](https://docs.lancedb.com/enterprise/v1-12-0/basics/catalog.md): configure your client.
* [Table versioning](https://docs.lancedb.com/enterprise/v1-12-0/management/table.md#versioning): read and restore retained versions.
* [Guarantees](https://docs.lancedb.com/enterprise/v1-12-0/basics/guarantees.md): understand commit and failure boundaries.

For invalid vector handling during ingestion, see
[Create a table](https://docs.lancedb.com/enterprise/v1-12-0/ingestion/create-table.md#from-a-custom-schema).


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