RTE reads

Applies to: Embedded ✅, Enterprise ✅ A table with the real time engine enabled queries the same way as any other table — nothing about search, filtering, or SQL changes. This page covers what you get back; for enabling RTE and writing to a table, see RTE writes. For how Enterprise combines these results across machines, see Distributed RTE Read.

Query a real time table

Every query runs against the base table and the fresh tier (unflushed memtables and SSTables) in parallel, and the two are merged into one result. Fresh rows supersede base rows with the same primary key, so a row written a moment ago is already reflected:

# continuing the `frames` table connected and written to in RTE writes
import numpy as np

query_vector = np.random.rand(frames.schema.field("embedding").type.list_size).astype("float32")

frames.search(query_vector, vector_column_name="embedding").limit(10).to_list()
frames.search("gripper closing on a cup", fts_columns="caption").limit(10).to_list()

By default every index on the table is RTE-maintained, re-read as the table changes, so a new index is picked up automatically; pin a smaller set with RTEWriteSpec.with_maintained_indexes. For full-text and scalar (BTree, bitmap) indexes, a maintained index covers every tier — base table, SSTables, and the active memtable — so a query rejects outright rather than silently skipping un-compacted rows if a resident memtable predates the index. Vector (ANN) search is maintained on the base table and SSTables the same way, and the active memtable builds its own in-memory HNSW graph as rows land, so writes stay vector-searchable within milliseconds too, without waiting on a freeze into an SSTable. That graph search steps aside for a full scan of the memtable only when it can’t honor the query through a graph — a prefilter, a primary-key override, a distance lower bound, or before the memtable has any index yet on a cold start.

Embedded: one process, one dataset

LanceDB Embedded runs this same LSM scanner directly against the local Lance dataset, in-process — the identical merge-by-primary-key logic, the same maintained-index rules for vector, full-text, and scalar search, just with no network hop to a separate serving tier. There is no WAL node to route to and nothing to combine across machines: a query against an RTE-enabled Embedded table already reads the fresh tier together with the base table in one call. See Distributed RTE Read for what Enterprise adds on top when that fresh tier is served by a separate machine from the one answering the rest of the query. Not every query shape runs through the LSM scanner — a query that asks for with_row_id, time travel, multiple query vectors, hybrid search, or a handful of other combinations is rejected with a clear error asking you to set use_rte(False) and read the base table only, rather than silently returning a result that omits un-compacted rows.

Limitations

Support for all table operations on RTE tables is coming soon. Time travel, count_rows, row IDs (with_row_id), and TABLESAMPLE are not yet available.

Next steps

RTE writes — enable RTE and write to a table
Distributed RTE Read — combining results across machines in Enterprise
How the real time engine works
Hybrid search
Vector search

Introduction

Getting Started

Concepts

Data Ingestion

Search

Data Curation

Feature Engineering

Training

Management

Maintenance

Security

Deployment

SQL Reference

Query a real time table

Embedded: one process, one dataset

Limitations

Next steps

​Query a real time table

​Embedded: one process, one dataset

​Limitations

​Next steps

Query a real time table

Embedded: one process, one dataset

Limitations

Next steps