What is the difference between a Feast entity and a feature view?

An entity is the business key used to look up features, such as a customer or product. A feature view is a named group of feature columns attached to one or more entities. The feature view also describes where those values come from and which timestamp Feast should use for historical correctness.

Why is point-in-time retrieval important in Feast?

Point-in-time retrieval prevents future information from leaking into training data. Given an entity key and an event timestamp, Feast selects feature values that would have been available at that moment. Without that constraint, a normal join may use later values and produce a model that looks stronger offline than it is in production.

Does Feast compute the features for me?

Not usually in the sense people first assume. Feast primarily defines, organises, retrieves, and serves features. The feature values are commonly produced by upstream pipelines, warehouse transformations, batch jobs, or streams. Feast then knows how to find them, join them correctly for training, and materialise them for online serving.

When should an online store be used with Feast?

Use an online store when a production service needs feature lookups during inference with low latency. Feast copies, or materialises, feature values from offline sources into a serving database. If predictions are only batch-scored from warehouse data, offline retrieval may be enough and an online store may add unnecessary operational work.

Feast Feature Store Walkthrough

A Feast feature store walkthrough is the practical path through modelling entities, data sources, feature views, and retrieval in Feast so the same feature definitions can produce point-in-time-correct training data and low-latency online features for inference.

The problem Feast addresses is not merely storing feature tables. It is keeping training and serving aligned when features are produced at different times, stored in different systems, and joined to examples by business keys. A plain warehouse join can silently attach values that were not available when the prediction would have been made. That creates label leakage and makes offline model quality look better than the production model can actually achieve.

In Feast, you describe the feature world as code and metadata. An entity is the key being predicted about, such as a customer, account, product, or driver. A data source points to where feature rows live, such as a warehouse table, parquet data, or a stream. A feature view groups related columns, says which entity they attach to, and identifies the event timestamp Feast must use when reconstructing historical values.

For training, Feast receives entity keys with event times and performs point-in-time retrieval, choosing feature values that were valid as of each event rather than simply the latest row. For online inference, Feast materialises selected feature values from the offline source into a low-latency online store such as Redis or DynamoDB. The application then asks for features by entity key and receives the latest available values under the same registered names.

The trade-off is operational discipline. Feast does not remove the need to compute correct features, schedule materialisation, monitor freshness, or design good keys and timestamps. It adds a registry, definitions, retrieval APIs, and online storage to manage. A common misunderstanding is that a feature store automatically guarantees feature quality. It depends on whether source data, timestamp semantics, backfills, and materialisation jobs are correctly designed.

Engineers meet Feast when building a repeatable machine learning pipeline: defining feature repositories, registering feature views, generating training datasets, loading online stores, and calling feature retrieval from an inference service. Data engineers tend to work on sources, timestamps, joins, and freshness. Machine learning engineers tend to care that training code and serving code request the same features without duplicating SQL or hand-written lookup logic.

Go deeper

Everything DataFeast Feature Store WalkthroughDefine Feast entities, feature views, data sources, and retrieval logic for both training and online inference.Open the lesson

Common questions

What is the difference between a Feast entity and a feature view?: An entity is the business key used to look up features, such as a customer or product. A feature view is a named group of feature columns attached to one or more entities. The feature view also describes where those values come from and which timestamp Feast should use for historical correctness.
Why is point-in-time retrieval important in Feast?: Point-in-time retrieval prevents future information from leaking into training data. Given an entity key and an event timestamp, Feast selects feature values that would have been available at that moment. Without that constraint, a normal join may use later values and produce a model that looks stronger offline than it is in production.
Does Feast compute the features for me?: Not usually in the sense people first assume. Feast primarily defines, organises, retrieves, and serves features. The feature values are commonly produced by upstream pipelines, warehouse transformations, batch jobs, or streams. Feast then knows how to find them, join them correctly for training, and materialise them for online serving.
When should an online store be used with Feast?: Use an online store when a production service needs feature lookups during inference with low latency. Feast copies, or materialises, feature values from offline sources into a serving database. If predictions are only batch-scored from warehouse data, offline retrieval may be enough and an online store may add unnecessary operational work.

Every term