Skip to main content

Feast Feature Store: Offline/Online Feature Management

Feast is the open-source feature store that eliminates train-serve skew. Define features once, use them consistently in both training pipelines and low-latency production serving — with point-in-time correct historical retrieval built in.

✓ Point-in-time correct training data ✓ Sub-ms online feature serving (Redis) ✓ Cloud-agnostic (BigQuery/Redshift/Parquet) ✓ Eliminates train-serve skew
Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →

Defining Features & the Feature Registry

Install with pip install feast[redis,gcp], initialize a repo, then define features in Python:

# feast init my_feature_repo && cd my_feature_repo
# feature_repo/features.py

from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource, FeatureStore
from feast.types import Float32, Int64, String

# Entities are the primary keys of your data (user_id, item_id, etc.)
user = Entity(name="user_id", description="User entity")
item = Entity(name="item_id", description="Item entity")

# Data source — Parquet for local, BigQuery/Redshift for cloud
user_stats_source = FileSource(
    path="data/user_stats.parquet",
    timestamp_field="event_timestamp",    # required for point-in-time joins
)

# FeatureView — defines a group of features from a single source
user_stats_view = FeatureView(
    name="user_statistics",
    entities=[user],
    ttl=timedelta(days=7),                # max feature age
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_order_value_30d", dtype=Float32),
        Field(name="days_since_last_purchase", dtype=Int64),
        Field(name="preferred_category", dtype=String),
    ],
    source=user_stats_source,
    tags={"team": "recommendations", "version": "v2"},
)

# Apply to registry: feast apply

Offline Store: Point-in-Time Training Data

Generate training datasets with correct historical feature values at each event's timestamp:

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

store = FeatureStore(repo_path=".")

# Entity DataFrame: for each (user_id, event_timestamp), retrieve features
# as they existed AT that timestamp (no future leakage)
entity_df = pd.DataFrame({
    "user_id": [1001, 1002, 1003, 1004],
    "event_timestamp": [
        datetime(2024, 1, 15, 10, 0),
        datetime(2024, 2, 3, 14, 30),
        datetime(2024, 3, 22, 9, 15),
        datetime(2024, 4, 1, 11, 45),
    ],
    "label": [1, 0, 1, 0],    # your target variable
})

# Point-in-time join — retrieves historical feature values for each row
training_data = store.get_historical_features(
    entity_df=entity_df,
    features=[
        "user_statistics:purchase_count_7d",
        "user_statistics:avg_order_value_30d",
        "user_statistics:days_since_last_purchase",
        "user_statistics:preferred_category",
    ],
).to_df()

print(training_data.head())
# user_id | event_timestamp | purchase_count_7d | avg_order_value_30d | label
# 1001    | 2024-01-15      | 3                 | 45.20               | 1

Online Store: Low-Latency Feature Serving

Materialize features to Redis, then serve at sub-millisecond latency in production:

from feast import FeatureStore
import subprocess
from datetime import datetime

store = FeatureStore(repo_path=".")

# Materialize features to online store (schedule as cron job)
# CLI: feast materialize-incremental $(date -u +%Y-%m-%dT%H:%M:%S)
store.materialize_incremental(end_date=datetime.utcnow())

# --- In your serving code (FastAPI, gRPC, etc.) ---
from fastapi import FastAPI

app = FastAPI()

@app.post("/predict")
async def predict(user_id: int):
    # Retrieve latest features from Redis — ~0.5ms latency
    feature_vector = store.get_online_features(
        features=[
            "user_statistics:purchase_count_7d",
            "user_statistics:avg_order_value_30d",
            "user_statistics:days_since_last_purchase",
        ],
        entity_rows=[{"user_id": user_id}],
    ).to_dict()

    # Identical features to what the model saw during training
    X = [[
        feature_vector["purchase_count_7d"][0],
        feature_vector["avg_order_value_30d"][0],
        feature_vector["days_since_last_purchase"][0],
    ]]
    prediction = model.predict(X)[0]
    return {"user_id": user_id, "prediction": float(prediction)}

Feast vs Tecton vs Hopsworks vs Vertex Feature Store

Feature Feast Tecton Hopsworks Vertex FS
Open-sourceYes (Apache 2.0)No (SaaS)Yes (AGPL)No (GCP-managed)
Real-time featuresStream FeatureViewNative streamingSpark StreamingDataflow-based
Point-in-time joinsBuilt-inBuilt-inBuilt-inBuilt-in
Cloud agnosticYes (any cloud)AWS-focusedAny cloud / on-premGCP only
Managed serviceSelf-managedFully managedSelf / managedFully managed
Best forSelf-hosted, flexibleEnterprise AWSFull platformGCP users

Frequently Asked Questions

What is a feature store and why do ML teams need one?▼

A feature store is a centralized system for storing, serving, and reusing ML features. Without it, different teams independently compute the same features (e.g., 'user's 7-day purchase total') in inconsistent ways, causing train-serve skew — the model sees different feature values during training vs production. A feature store ensures features are computed once, stored consistently, and served identically to both the training pipeline and the production inference service.

What is the difference between Feast's offline and online stores?▼

The offline store (BigQuery, Redshift, Parquet files, Hive) stores historical feature values for training data generation. It supports point-in-time correct joins: for each training example at time T, retrieve feature values as they existed at time T, preventing future data leakage. The online store (Redis, DynamoDB, Bigtable, Cassandra) stores only the latest feature values for low-latency inference — typically sub-millisecond lookups. Materialization copies data from offline to online.

What is a point-in-time join and why is it critical?▼

A point-in-time join retrieves historical feature values as they existed at a specific timestamp, preventing data leakage in training datasets. If you're training a fraud model and join today's 'account_age_days' feature to a 2023 transaction, you'd get the wrong value (the account is older now than it was in 2023). Feast's get_historical_features() automatically performs these point-in-time joins using the event_timestamp in your entity DataFrame.

What is feature materialization in Feast?▼

Materialization is the process of copying feature values from the offline store to the online store so they are available for low-latency serving. Run feast materialize-incremental $(date -u +%Y-%m-%dT%H:%M:%S) to copy features updated since the last materialization. This is typically scheduled as a cron job. After materialization, feast.get_online_features() retrieves values from Redis/DynamoDB in microseconds instead of querying BigQuery.

How does Feast handle feature freshness?▼

Feast tracks max_age at the FeatureView level — if a feature value is older than max_age, it returns null instead of a stale value. This prevents serving severely outdated features. For real-time features (e.g., current cart value), use Stream FeatureViews backed by Kafka/Kinesis that continuously update the online store. For batch features (e.g., weekly user segment), daily materialization is typically sufficient.

When should I use Feast vs Tecton vs Hopsworks?▼

Use Feast when you want an open-source, cloud-agnostic feature store that you fully control — it integrates with your existing data warehouse and Redis. Use Tecton if you're on AWS and need a fully managed solution with real-time feature pipelines and SLA guarantees. Use Hopsworks if you need the full feature platform including built-in feature monitoring, feature store UI, and integration with Python/Spark pipelines in one managed system. Feast is the most flexible but requires more operational work.