Feast is the open-source feature store that most teams reach for once they hit the same wall: training pipelines and serving pipelines computing the same feature two different ways, and nobody noticing until predictions drift. Feast doesn't compute features for you — it standardizes how they're defined, stored, and retrieved consistently between offline training and online serving.
What Feast actually solves
The core problem is training/serving skew. A data scientist computes "average order value over the last 30 days" in a batch notebook against a warehouse table; the same feature gets reimplemented in application code for real-time inference, usually with a subtly different window or null-handling rule. Feast's answer is a feature registry — a central definition of each feature, its data type, and its source — paired with two retrieval paths: point-in-time-correct joins for training sets, and low-latency key lookups for online serving, both reading from the same feature definitions.
Feature views and entities
Feast organizes features around entities (the join key, like customer_id) and feature views (a group of features computed from a data source, tied to an entity and a TTL). You define feature views in Python against a source — a BigQuery table, a Parquet file on S3, a Snowflake table — and Feast handles pulling the right historical values for a given entity and timestamp when you build a training set, so features never leak information from after the label's event time.
Anyone can write a join. What Feast gives you is a join that respects event timestamps automatically, so a feature computed with data from after the prediction point never sneaks into a training row. This class of bug is quiet and produces models that look great offline and fail in production.
Offline store vs. online store
Feast separates where historical features live from where low-latency features live. The offline store (BigQuery, Snowflake, Redshift, or a data warehouse of your choice) serves training-set generation. The online store (Redis, DynamoDB, or Feast's own key-value backends) serves real-time inference with millisecond lookups by entity key. A materialization step — feast materialize — pushes the latest feature values from the offline store into the online store on a schedule, which is the mechanism that keeps the two in sync.
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32
from datetime import timedelta
customer = Entity(name="customer_id", join_keys=["customer_id"])
orders_source = FileSource(
path="data/orders_stats.parquet",
timestamp_field="event_timestamp",
)
customer_stats_view = FeatureView(
name="customer_order_stats",
entities=[customer],
ttl=timedelta(days=30),
schema=[Field(name="avg_order_value_30d", dtype=Float32)],
source=orders_source,
)Where teams get it wrong
The most common mistake is adopting Feast before there's a second consumer of the features. If only one training pipeline uses a feature, a feature store adds registry and materialization overhead for no skew-prevention benefit — a shared library function does the same job more cheaply. Feast earns its complexity when at least two systems (a training job and a serving API, or two models) need the same feature computed identically. The second mistake is treating materialization latency as zero; if your online store refreshes hourly, features used for real-time decisions are up to an hour stale, which is fine for "customer's average order value" and not fine for "current cart total."
Feast doesn't run your feature transformations — you still need Spark, dbt, or a batch job to produce the underlying tables. Feast is the registry, the point-in-time join logic, and the online/offline sync, not the ETL itself.
Wrapping up
Reach for Feast once you have real training/serving skew risk — multiple consumers of the same feature, a gap between batch training and real-time inference — not because "feature store" sounds like the mature next step. The value is entirely in consistent, point-in-time-correct feature retrieval across offline and online paths; everything else is still your own pipeline code.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.