Skip to main content
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. 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.
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.
consistency.py
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

For invalid vector handling during ingestion, see Create a table.