Training and serving from the same lakehouse table.
Training/serving skew happens when your batch features and your online features are computed from different data sources. DataLynxr's point-in-time reads eliminate the problem at the source — there is only one source.
$ python
from datalynxr import LakehouseClient
client = LakehouseClient(workspace="my-org")
train_df = client.get_feature_values(
... table="user_features",
... entity_ids=user_ids,
... timestamp=label_timestamps,
... )
live_features = client.get_feature_values(
... table="user_features",
... entity_ids=[user_id],
... )
✓ Zero skew — same source, same pathWhat you get with DataLynxr ML
Point-in-time correct reads
Specify the exact timestamp for each entity. DataLynxr uses table time-travel to return only feature values that were known at that timestamp — no future data leakage.
Zero training/serving skew
Training and serving use the same get_feature_values() API against the same lakehouse table. No separate batch/online compute divergence.
Python SDK
Native Python client returns Pandas DataFrames or PyArrow Table objects. Works with any ML framework — scikit-learn, XGBoost, PyTorch, JAX.
Lakehouse tables as feature tables
Any Delta or Iceberg table becomes a feature source — tables written by your SQL jobs, streaming pipelines, or existing ETL. No separate feature registration required.
No separate feature store infra
No Redis, no DynamoDB, no Feast. Your existing lakehouse storage is the feature store. No additional latency tier, no data sync, no cost for a parallel system.
Lineage and audit trail
Every feature value served or used in training is traceable back to the specific lakehouse snapshot. Audit-ready lineage for model governance.
Retire your duplicate feature stores.
One lakehouse table for training and serving. Try it with a free account — no credit card.