Feast: an offline/online feature store that keeps training and serving in sync

The problem Feast addresses: two paths to the same feature value

A model is trained on historical rows and then served on live rows. Those two paths are usually built by different code. Training reads from a warehouse with a SQL join; serving reads from Redis or a similar key-value store with a point lookup. Nothing enforces that the join and the lookup compute the same value, and nothing enforces that the training join only used data that existed at the event timestamp. The README frames the second hazard directly: Feast generates point-in-time correct feature sets so that future feature values do not leak into training. That is the concrete failure it targets. A churn model trained on a customer's lifetime value as of today, then evaluated against a label from last month, scores well offline and fails in production. Feast's audience is the ML platform team that owns this plumbing for several models, not the data scientist writing a one-off notebook. The README describes three jobs for that team: keep features consistently available for training and serving, avoid data leakage through point-in-time correct sets, and decouple ML from data infrastructure through a single data access layer.

Offline store, online store, feature server: what each component actually holds

The README describes a minimal deployment with three moving parts. The offline store processes historical data for batch scoring or model training. The online store is low-latency storage that powers real-time prediction. The feature server serves pre-computed features online. Feature definitions live in a repository that you register with the CLI; the same definitions are then read by both the historical and the online retrieval APIs. That shared definition is the mechanism behind train/serve consistency. In the README's example, one feature view named driver_hourly_stats exposes conv_rate, acc_rate and avg_daily_trips, and the same string identifiers ('driver_hourly_stats:conv_rate') appear in the training call and in the online call. The offline path takes an entity dataframe with driver_id and event_timestamp columns and returns a dataframe. The online path takes entity rows and returns a dict keyed by entity and feature name. Because both sides resolve the same feature view, a change to the definition propagates to both, which is the property you cannot get from two hand-written pipelines. Note what the architecture diagram is labelled as: the minimal Feast deployment. The README points elsewhere for running the full stack on Snowflake, GCP or AWS, so the local picture is a starting point, not the production topology.

Getting a repository running: init, apply, materialize, serve

The README's getting-started sequence is four commands and two Python calls. Install with pip install feast. Create a repository with feast init my_feature_repo, then cd into my_feature_repo/feature_repo. Register the definitions and set up the store with feast apply. There is an experimental web UI available via feast ui. Training data comes from FeatureStore(repo_path=".").get_historical_features(entity_df=..., features=[...]).to_df(), where entity_df carries the entity key and an event_timestamp column. Moving values into the online store has three documented options. The README marks incremental materialization as recommended: CURRENT_TIME=$(date -u +"%Y-%m-%dT%H:%M:%S") followed by feast materialize-incremental $CURRENT_TIME. Full materialization takes explicit bounds: feast materialize 2021-04-12T00:00:00 $CURRENT_TIME. The third option, feast materialize --disable-event-timestamp, materializes all available feature data using the current datetime as the event timestamp. The README says this is for source data that lacks proper event timestamp columns. That flag is the one to read carefully, because it changes what the stored event timestamp means. Serving is store.get_online_features(features=[...], entity_rows=[{"driver_id": 1001}]).to_dict(), which returns a dict with the entity key and feature values. The README's example output shows conv_rate 0.49274, acc_rate 0.92743 and avg_daily_trips 72 for driver 1001.

Materialization is the operational cost, and it is scheduled work

Nothing in the online path is free. Values reach the online store only when a materialization job runs, so the freshness of every real-time prediction is bounded by the interval between those jobs. The README gives three ways to run one and recommends the incremental form, which implies the store tracks a watermark and advances it. The full form requires you to supply both a start and an end timestamp, and the README's example output line reads Materializing feature view driver_hourly_stats from 2021-04-14 to 2021-04-15 done! The --disable-event-timestamp variant is the one with a real caveat: if your source data has no event timestamp column, Feast substitutes the current datetime, which means point-in-time correctness is no longer being enforced by the source data itself. For a feature that changes slowly this may be acceptable. For anything that behaves like a running counter, it is a quiet way to reintroduce the leakage problem Feast exists to prevent. The README does not describe a built-in scheduler for materialization, so the trigger is your orchestration system, and the failure mode when that trigger stops is stale online features rather than an error. That is the least visible thing in this project and the thing most worth monitoring.

Where Feast is the wrong tool

If your model trains nightly and writes its predictions back to the same warehouse, you have one path, not two, and there is no consistency gap for Feast to close. You would be adding a repository, a CLI step, an online store and a materialization job to a pipeline that already works. The same applies when a single feature view serves one model and the join logic fits in a few lines of SQL that a reviewer can read. The cost of Feast is not the install; it is the extra moving parts and the operational discipline of keeping materialization running. There is also a scaling question the README does not answer. It presents the architecture diagram as the minimal deployment and links out for Snowflake, GCP and AWS setups, so anything about throughput, latency under load, or how large a feature repository can grow before the CLI becomes slow is outside what this material establishes. Treat those as things to measure in your own environment rather than assumptions. Finally, the web UI is labelled experimental, so it should not be the interface your team depends on for inspecting feature definitions.

Feast versus a plain warehouse query, and versus a managed store

The honest alternative for a batch-only team is not another feature store. It is the SQL join you already write, plus a test that asserts the training query and the scoring query produce identical columns. That approach has no online component, no materialization schedule, and no new service to operate. It breaks down at the moment you need a low-latency lookup per request, because a warehouse query is the wrong shape for that access pattern. The other alternative is a managed feature store tied to one cloud vendor. The difference in approach is where the abstraction sits. Feast positions itself as a single data access layer that abstracts feature storage from feature retrieval, so models stay portable as you move from one data infrastructure system to another. A vendor-managed store buys you less operational work but ties the definitions and the runtime to that vendor. Feast's portability claim is a design intent stated in the README, not a guarantee about any specific migration, so weigh it as direction rather than proof. If you are already committed to one cloud's stack and do not expect to move, the portability argument carries less weight than the operational savings.

Licence, releases and what an upgrade actually involves

Feast is Apache-2.0, which permits commercial use and modification and includes a patent grant. That is a permissive licence, and this is not legal advice; if you redistribute Feast or build it into a product, read the licence text and your own counsel's guidance rather than a summary. On cadence, the release history shows v0.66.0 on 2026-08-21, v0.65.0 on 2026-07-20 and v0.64.0 on 2026-06-13, so roughly monthly minor releases on the 0.x line, with the last push to master on 2026-09-09. The 0.x version number is the practical signal here. There is no 1.0, and the README labels at least one component (the web UI) as experimental, so you should expect interface movement between minor versions. Pin the feast version in your requirements file and read the release notes before bumping, because a change to feature definition semantics or to a store interface lands in your repository and in your materialization jobs at the same time. The README also notes that the README file itself is auto-generated from a Jinja2 template at infra/templates/README.md.jinja2, which tells you documentation changes are treated as build output rather than hand edits.

Editorial conclusion

Adopt Feast if you already serve predictions online and are hand-rolling joins between a warehouse and a key-value store, or if point-in-time correctness has already produced a leakage bug. Skip it if you train and score in one batch job against a single table, because the online store and feature server add components you will not query. Before committing, verify three things in a scratch repo: that feast apply works against your actual offline source, that feast materialize-incremental produces the entity rows your serving path expects, and that your chosen online store supports the entity key types in your feature views.

Official sources

1. feast-dev/feast on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases