FAQ
Connection
Yes! It is recommended to establish a single database connection and maintain it throughout your interaction with the tables within. LanceDB uses HTTP connections to communicate with the servers. By re-using the Connection object, you avoid the overhead of repeatedly establishing HTTP connections, significantly improving efficiency.
For optimal performance, table = db.open_table() should be called once and used for all subsequent table operations.
If there are changes to the opened table, the table always reflect the latest version of the data.
Indexing
We support IVF_PQ and IVF_HNSW_SQ as the index_type which is passed to create_index.
LanceDB Cloud tunes the indexing parameters automatically to achieve the best tradeoff
between query latency and query quality.
create_index is asynchronous. LanceDB, in the background, will figure out when to
trigger the index build job. When there are updates to the table data, we will optimize
the existing indices accordingly so that query performance is not impacted.
No! LanceDB Cloud triggers an asynchronous background job to index the new vectors.
Even though indexing is asynchronous, your vectors will still be immediately searchable.
LanceDB uses brute-force search to search over unindexed rows. This makes your new data
immediately available, but does increase latency temporarily.
To disable the brute-force part of search, set the fast_search flag in your query to true.
No! Similar to adding data to the table, LanceDB Cloud triggers an asynchronous background job to update the existing indices. Therefore, no action is needed from users and newly updated data will be available for search immediately. There is absolutely no downtime expected.
No! LanceDB will automatically optimize the FTS index for you. In the meanwhile, newly updated data will be available for search immediately.
This applies to scalar indices as well.
While LanceDB Cloud indexes are typically created quickly, best practices differ between index types:
- Full-Text Search (FTS) and Scalar Indexes
Queries executed immediately after
create_fts_indexorcreate_scalar_indexcalls may fail if the background indexing process hasn’t completed. Wait for index confirmation before querying. - Vector Indexes
Queries after
create_indexwill not generate errors, but may experience degraded performance during ongoing index optimization. For consistent performance, wait until indexing finishes.
It’s recommended to use list_indices to verify
index creation before querying. As an alternative, you can check out the table details
in the UI, the existing indices will show up.
You can call index_stats with the index name passed to check the number of
rows indexed/unindexed.
It is strongly recommended to create scalar indices on the filter columns. Scalar indices
will reduce the amount of data that needs to be scanned and thus speed up the filter.
LanceDB supports BITMAP, BTREE and LABEL_LIST as our scalar index types. You
can see more details here.
LanceDB implements an optimization algorithm to decide whether a delta index will be appended vs a full retrain on the index is needed.
Query
YES! LanceDB supports blazing fast vector search with metadata filtering. Both prefiltering (default) and postfiltering are supported. We have seen 30ms as the p50 latency for a dataset size of 15 million. You can see here for more details.
LanceDB Cloud currently does not support an ID or primary key column. You are recommended to add a user-defined ID column. To significantly improve the query performance with SQL clauses, a scalar BITMAP/BTREE index should be created on this column.
Multiple factors can impact query latency. To reduce query latency, consider the following:
- Send pre-warm queries: send a few queries to warm up the cache before an actual user query.
- Check network latency: LanceDB Cloud is hosted in AWS us-east-1 region. It is recommended to run queries from an EC2 instance that is in the same region.
- Create scalar indices: If you are filtering on metadata, it is recommended to create scalar indices on those columns. This will speed up searches with metadata filtering. See here for more details on creating a scalar index.
- For LanceDB Cloud users, yes, strong consistency is guaranteed.
- For LanceDB Enterprise users, strong consistency is set by default. However, you can
change the
weak_read_consistency_interval_secondsparameter on the query node to tradeoff between read consistency and query performance.
If you do not need to query from the unindexed data, you can call fast_search to
make queries fast, with the unindexed data missing.
Enterprise specific
Architecture and Fault tolerance
LanceDB Enterprise employs component-level replication to ensure fault tolerance and
continuous operations. While the system remains fully functional during replica
failures, transient performance impacts (e.g., elevated latency or reduced throughput)
may occur until automated recovery completes.
For architectural deep dives, including redundancy configurations,
please contact the LanceDB team.
The plan executor caches the table data, not the table indices.
LanceDB implemented highly performant consistent hashing for our plan executors. NVMe SSD caching is enabled by default for all deployments.
LanceDB’s plan executor is typically deployed with 2+ replicas for fault tolerance:
- Mirrored Caches: Each query replica maintains synchronized copies of data subsets, enabling low-latency query execution.
- Load Balancing: Traffic distributed evenly across replicas. With a single replica failure, there is no downtime - system remains operational with degraded performance, as the remaining replicas will handle all the traffic until the failed replica comes back online.
Consistency
By default, LanceDB Enterprise operates in strong consistency mode. Once a write is successfully acknowledged, a new Lance dataset version manifest file is created. Subsequent reads always load the latest manifest file to ensure the most up-to-date data.
However, this increases query latency and can place significant load on the storage system under high concurrency. We offer the following parameter to adjust consistency level.
weak_read_consistency_interval_seconds(default: 0) – Defines the interval (in seconds) at which the system checks for table updates from other processes. Recommended Setting: To balance consistency and performance, settingweak_read_consistency_interval_secondsto 30–60 seconds is often a good trade-off. This reduces unnecessary cloud storage operations while still keeping data reasonably fresh for most applications.
This setting only affects read operations. Write operations always remain strongly consistent.
Indexing
Yes! Please contact the LanceDB team to enable GPU based indexing for your deployment.
Then you just need to call create_index and backend will use GPU for indexing.
LanceDB is able to index a few billions of vectors under 4 hours.
Cluster configuration
LanceDB Enterprise offers granular control over performance, resilience, and operational behavior through a comprehensive set of parameters: replication factors for each component, consistency level, graceful shutdown time intervals, etc. Please contact the LanceDB team for a detailed documentation on such parameter configurations.
Monitoring and alerts
We have various metrics set up for monitoring each component in the LanceDB stack.
- query node: RPS, query latency, error codes, slow take count, CPU/memory utilization, etc.
- plan executor: SSD cache hit/miss, CPU/memory utilization, etc. Please contact the LanceDB team for the comprehensive list of the monitoring metrics.
LanceDB uses Prometheus for metrics collection and OpenTelemetry (OTel) to export such metrics with data enrichment. The LanceDB team will work with you to integrate the monitoring metrics with your preferred dashboard.
Others
Upgrade to a recent pylance version(v0.18.0+), then use LanceDataset.data_storage_version
>>> lance.dataset("my_dataset").data_storage_version
'2.0'