Completes the read half of #6899. LanceFormat landed in #6925 as a format descriptor; nothing read Lance until now.

Lance already worked through SparkSource, which drives its reader generically from table_format.format_type.value and table_format.properties. What was missing is a path that needs no JVM — which is also the real test of whether the DataSource abstraction is engine-agnostic rather than Spark-agnostic in name only.

Placement, and why not the two obvious alternatives

A new LanceSource read by the existing DuckDB store — not a Lance offline store, and not an extension of FileSource.

FileSource is the wrong host. Its format axis is already occupied by file_format (ParquetFormat/DeltaFormat), so adding table_format gives one source two overlapping format axes. It is also read by two stores with incompatible contracts: duckdb._read_data_source dispatches on type, while dask._read_datasource has no dispatch seam at all — it reads file_options.uri unconditionally as Parquet and hard-asserts isinstance(..., FileSource) in three places, so a third format would break silently under Dask. Decisively: Lance's catalog addressing (catalog/namespace/table) has no path to put in FileSource.path, so the catalog-based layer would not fit the class even if the path-based one did.

A Lance offline store would be the wrong 120 lines. duckdb.py is not an engine — it is a binding that injects _read_data_source/_write_data_source callbacks into the real engine in ibis.py. A LanceOfflineStore would be a near-verbatim copy of it plus a repo_config.py entry, and would force users to choose Lance instead of Parquet rather than mixing them in one feature service.

Reading a source as ibis.memtable(arrow_table) in the DuckDB store already has two precedents — IcebergSource and MlflowDatasetSource. Following them means ibis.py is untouched, so the point-in-time join, TTL handling, field mapping and ODFVs all work unchanged, and neither repo_config.py nor data_source.py needs an edit because CUSTOM_SOURCE + data_source_class_type is self-describing in the registry proto.

Net: +47 lines to duckdb.py, one new source module.

Both addressing modes work

# path-based
LanceSource(uri="s3://bucket/poi_embeddings.lance", timestamp_field="generated_at")

# catalog-based, through namespace_client + table_id
LanceSource(
    table="poi_embeddings",
    namespace_impl="rest",
    table_format=LanceFormat(catalog="my_catalog", namespace="features"),
    timestamp_field="generated_at",
)

Pin semantics: a pin selects data, never shape

Following what was argued on #5782 and #6925. Three things enforce it:

• get_table_column_names_and_types reads the pinned schema, so feast apply infers the schema reads will actually see.
• A pre-flight check in get_historical_features fails with a message naming the pin when a pinned version cannot satisfy the declared schema. It reads schemas only — one metadata round trip, no scan.
• Vector widths go through _validate_vector_field_lengths from fix: Make vector length validation reachable, schema-driven and vectorized #6909 rather than a second validator. This is exact for Lance because Lance stores vectors as fixed_size_list, where that check is a property of the Arrow type.

Demonstrated rather than asserted — the dataset is overwritten with a corrected value for the same (entity, timestamp), and the pinned read still returns the original:

latest  (        latest version): raw=[0.77, 1.17]  get_historical_features@12:30 -> 0.77
tag pin (    tag 'eval_2026_q1'): raw=[0.5,  0.9 ]  get_historical_features@12:30 -> 0.50
ver pin (             version 1): raw=[0.5,  0.9 ]  get_historical_features@12:30 -> 0.50

Testing

43 tests, all using the dir namespace implementation — it exercises the identical namespace_client + table_id code path as a remote catalog, so the suite needs no server. Point-in-time correctness is covered for both the path-based and catalog-based variants, with a 12:30 query selecting the 11:00 row and never the 13:00 one.

Regression evidence, rebased onto current master. Failure names compared rather than counts, since the suite has flaky members:

with this change : 40 failures
master           : 40 failures
only with change : (none)
only on master   : (none)

ruff check and ruff format --check clean on all four files. mypy --ignore-missing-imports clean. (Bare mypy reports pre-existing missing-stub noise for pyarrow/pandas/ibis/pyiceberg/deltalake; the repo has no mypy config section.)

Known limitations, deliberately

• Read-only. _write_data_source is untouched, so a LanceSource is not yet a persist target and there is no SavedDatasetLanceStorage. materialize into an online store does work, via pull_latest_from_table_or_query. Happy to follow up — _write_data_source already dispatches on IcebergSource, so the seam exists.
• DuckDB only. Dask cannot read Lance, by the reasoning above. RayOfflineStore would be a natural second host since it already has a _resolve_source_dataset dispatch, but it is not in this PR.
• Only the dir impl is exercised. rest, glue, unity, polaris and the Hive/Iceberg impls need lance-namespace-impls plus a live catalog. The code path is identical, which is why dir is a meaningful test, but I have not run against a remote catalog.
• Eager materialisation. The read pulls the dataset into Arrow before ibis sees it, matching what IcebergSource and MlflowDatasetSource already do. Column projection is pushed down via to_arrow(columns=...), but the retrieval path does not pass a projection and no predicate pushdown reaches Lance.
• Vector-width validation is exact only for fixed_size_list. For a plain list/large_list column the pre-flight runs on a zero-row table and infers nothing. Lance writes fixed_size_list, so this is the right trade in practice. Making it exact in general needs the feature view threaded into the data_source_reader callback in ibis.py, whose signature is (DataSource, str) — a separate change that would benefit every source, not just this one.

Related: #6899, #6925, #6909, #5782, #5652