# Feast: the open source feature store for training and online inference

> Feast separates offline feature storage from a low-latency online store and serves both through one Python API. The install is one pip command, but the point-in-time correctness and materialization model decide whether it fits your stack.

**feast-dev/feast** — The Open Source Feature Store for AI/ML

- Repository: https://github.com/feast-dev/feast
- Website: https://feast.dev
- Stars: 7,319 · Forks: 1,463
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/feast-dev-feast

## The problem Feast solves: one feature definition, two access paths

Training pipelines and prediction services usually read the same feature from different places. A data scientist joins a warehouse table with an entity dataframe; a service reads a key-value store. The two paths drift, and the drift shows up as training-serving skew. Feast addresses that by making a feature definition the single source of truth and deriving both paths from it. The README states the goal plainly: manage an offline store for historical data, a low-latency online store for real-time prediction, and a feature server for serving precomputed features.

The second problem is leakage. When you join feature tables to labels by hand, it is easy to pick a row whose timestamp is later than the label timestamp. Feast generates point-in-time correct feature sets, so a training row only sees feature values that existed at that moment. The README frames this as letting data scientists focus on feature engineering rather than debugging join logic.

Who it is for: ML platform teams, not individual model authors working alone. The architecture assumes someone owns infrastructure decisions, because the offline and online stores are pluggable and you have to choose them.

## Offline store, online store, registry and the feature server

The minimal deployment in the architecture diagram has four moving parts. The offline store holds historical feature data and answers get_historical_features queries. The online store holds the latest value per entity key and answers get_online_features. The registry records entities, feature views and data sources, and it is what feast apply writes. The feature server exposes the online path over HTTP so a prediction service does not need the Python SDK.

Data flows in one direction for serving: source data is materialized from the offline store into the online store, and the feature server reads from the online store. Materialization is therefore the operation that decides how fresh online features are. The README offers three commands for it, and the difference matters. feast materialize-incremental takes a single end timestamp and is marked recommended. feast materialize takes explicit start and end timestamps. feast materialize --disable-event-timestamp uses the current datetime as the event timestamp for all available data, which the README says is useful when source data lacks proper event timestamp columns.

The repository layout confirms the split is real rather than conceptual. There is an sdk/ directory for Python, a go/ directory with a go.mod that pulls in the AWS SDK, Redis, pgx and the Google Cloud storage client, and a java/ directory. The online store implementations live in those language trees, which is why the Python package declares them as optional dependencies instead of installing everything.

## Installing Feast and building a first training set

Feast requires Python 3.10 or newer according to pyproject.toml. The README's getting started section installs the base package with pip, and no extra index or build step is mentioned.

```bash
pip install feast
```

Next, scaffold a repository. feast init creates the directory structure and a sample feature_repo, and the README then changes into it.

```bash
feast init my_feature_repo
cd my_feature_repo/feature_repo
```

Register the definitions. This is the step that writes the registry and provisions the online store infrastructure.

```bash
feast apply
```

The README also documents an experimental web UI, started with feast ui, for exploring the repository. Treat it as a convenience for inspection, not as a production surface.

The first real use is a point-in-time join. You supply an entity dataframe with entity keys and event timestamps, name the features as feature_view:feature, and Feast returns the values that were current at each timestamp.

```python
from feast import FeatureStore
import pandas as pd
from datetime import datetime

entity_df = pd.DataFrame.from_dict({
    "driver_id": [1001, 1002, 1003, 1004],
    "event_timestamp": [
        datetime(2021, 4, 12, 10, 59, 42),
        datetime(2021, 4, 12, 8, 12, 10),
        datetime(2021, 4, 12, 16, 40, 26),
        datetime(2021, 4, 12, 15, 1, 12)
    ]
})

store = FeatureStore(repo_path=".")

training_df = store.get_historical_features(
    entity_df=entity_df,
    features=[
        'driver_hourly_stats:conv_rate',
        'driver_hourly_stats:acc_rate',
        'driver_hourly_stats:avg_daily_trips'
    ],
).to_df()
```

Before any of that reaches a prediction service, the values have to be in the online store. Incremental materialization is the recommended form, and it takes the current UTC time as its argument.

```bash
CURRENT_TIME=$(date -u +"%Y-%m-%dT%H:%M:%S")
feast materialize-incremental $CURRENT_TIME
```

Online reads then return a dictionary keyed by entity and feature name. The README's example shows the entity column and the feature columns, with the feature view name joined to the feature name by a double underscore.

```python
from feast import FeatureStore

store = FeatureStore(repo_path=".")

feature_vector = store.get_online_features(
    features=[
        'driver_hourly_stats:conv_rate',
        'driver_hourly_stats:acc_rate',
        'driver_hourly_stats:avg_daily_trips'
    ],
    entity_rows=[{"driver_id": 1001}]
).to_dict()
```

## Where Feast adds work instead of removing it

The online store is not free. Every feature you want at prediction time must be materialized, and materialization is a scheduled job you now own. If the job fails silently, the feature server keeps answering, just with stale values. The README documents the materialization commands but does not document rollback of a bad materialization or a built-in freshness alarm, so monitoring the gap between source data and online values is on you.

The web UI is labelled experimental in the README. Teams that put it behind a shared URL should read that label as a statement about API stability, not modesty.

The dependency surface is another cost. The base install pulls in Dask, pandas, pyarrow, FastAPI, uvicorn, gunicorn, SQLAlchemy and Prometheus client, among others. If you only wanted a point-in-time join helper, that is a large footprint. And the specific online store you need is almost certainly an extra: pyproject.toml declares separate optional groups for aws, azure, cassandra, clickhouse, couchbase, delta, duckdb, elasticsearch and more. Installing feast alone does not give you a Redis or DynamoDB backend.

Finally, this is the wrong tool for pure batch scoring. If every prediction happens in a warehouse job and nothing needs single-digit millisecond reads, the online store and feature server are components you will run and never use.

## Feast against a warehouse-native feature table

The realistic alternative is not another feature store but staying in the warehouse. dbt models plus a scheduled job that writes a feature table, and a serving layer that reads the same table, is a common setup. The difference is where correctness lives. With warehouse tables, point-in-time correctness is a join you write and review each time; with Feast, it is a property of the entity dataframe and the feature view definitions, and get_historical_features enforces it. That is the trade: Feast takes on the join logic and the online path in exchange for a registry, a materialization job and a set of pluggable stores.

A second alternative is to keep the online path but skip the feature store: write features to a key-value store directly from the same job that computes them. That is simpler until two teams need the same feature, or until the training query and the serving write diverge. Feast's value shows up at the second consumer, not the first.

If you do choose Feast, the practical question is which online store. The repository ships implementations across its Python and Go trees, and the extras in pyproject.toml are the authoritative list of what is installable without building from source.

## Licence, releases and what upgrades cost

Feast is Apache-2.0, declared both in the repository LICENSE file and in pyproject.toml through the license field. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you keep the licence and notice files. That is the general shape of the licence, not advice about your situation. If you redistribute Feast inside a product, have counsel read the NOTICE and patent-termination clauses rather than relying on a summary.

On cadence, the release history shows v0.64.0 on 2026-06-13, v0.65.0 on 2026-07-20 and v0.66.0 on 2026-08-21, with the last push to master on 2026-09-09. Version numbers stay below 1.0, so the project does not promise a stable API in the semver sense. Pin the version in your own requirements and read the changelog before moving, because the optional dependency groups and the store implementations are where breakage tends to land.

The upgrade cost is mostly environmental. Because online stores arrive as extras, a version bump can change a store's dependency range without changing your feature definitions. Test feast apply and one materialization run against a staging registry before touching production, and keep the registry under version control so you can see what changed.

## Conclusion

Adopt Feast if you already run a data warehouse and need point-in-time correct training sets plus a low-latency online path without moving feature logic into the serving stack. Do not adopt it if you only need batch scoring from a warehouse, since the online store and feature server add components you will not use. Before committing, verify that your chosen online store is in the optional-dependency list in pyproject.toml, and run feast apply against a throwaway repository to confirm the registry and infrastructure are created as you expect.

## FAQ

### What does a feast mean in the context of the Feast feature store?

The name is a contraction of Feature Store, per the README. Feast is an open source feature store for machine learning, distributed under Apache-2.0, that manages an offline store for training data and a low-latency online store for inference.

### How do you install Feast?

The README's getting started section installs the base package with pip install feast, then runs feast init to create a feature repository and feast apply to register definitions. Individual online stores such as aws, azure, cassandra or clickhouse are separate optional dependency groups in pyproject.toml.

### How do you materialize features into the online store in Feast?

The README gives three forms: feast materialize-incremental with a single current timestamp, which it marks recommended; feast materialize with explicit start and end timestamps; and feast materialize --disable-event-timestamp, which uses the current datetime as the event timestamp for all available data when the source lacks proper event timestamp columns.

### What Python version does Feast require?

pyproject.toml sets requires-python to >=3.10.0 and classifies the package for Python 3.10, and the Makefile lists 3.10, 3.11 and 3.12 as the versions it tests against.

### What licence does Feast use?

Feast is Apache-2.0, declared in the repository LICENSE file and in the license field of pyproject.toml. Apache-2.0 allows commercial use and modification and includes a patent grant, with the usual requirement to retain licence and notice files.

## Sources

- [feast-dev/feast on GitHub](https://github.com/feast-dev/feast)
- [License: Apache-2.0](https://github.com/feast-dev/feast/blob/master/LICENSE)
- [Project website](https://feast.dev)
- [README](https://github.com/feast-dev/feast/blob/master/README.md)
- [Releases](https://github.com/feast-dev/feast/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/feast-dev-feast