Overview

Feast (Feature Store) is an open-source project designed to address the challenges of managing machine learning features at scale. It acts as a centralized repository for feature definitions and values, enabling teams to build, deploy, and monitor ML models more efficiently. The core problem Feast aims to solve is the discrepancy and redundancy often found when features are separately engineered for training and inference, or across different models and teams.

Feast provides a Python SDK to define features from various data sources, such as data warehouses (e.g., Snowflake, BigQuery) and streaming platforms (e.g., Kafka). Once defined, features are registered in Feast, allowing them to be retrieved consistently for both historical model training (offline store) and real-time predictions (online store). This consistency is critical for preventing training-serving skew, a common issue where discrepancies between training and serving data lead to degraded model performance.

The system is particularly well-suited for organizations that are deploying multiple machine learning models and require a standardized way to manage their feature pipelines. By centralizing feature definitions, Feast helps reduce operational overhead and promotes collaboration among data scientists and ML engineers. It supports a flexible architecture, allowing integration with existing data infrastructure and machine learning platforms. For instance, it can integrate with orchestration tools like Airflow for feature pipeline automation and with model serving frameworks for real-time feature retrieval.

Feast is licensed under Apache 2.0, which means it is free to use and modify, making it an option for enterprises seeking to implement a feature store without proprietary vendor lock-in. Its architecture separates the feature definition layer from the underlying data storage and serving layers, providing flexibility in choosing technologies best suited for specific use cases and existing infrastructure. This design allows users to swap out different online or offline stores as needed, adapting to evolving data ecosystems.

Key features

  • Feature Definition and Registration: Define features using a declarative Python API, specifying data sources, transformations, and types. Features are then registered in a central registry for discovery and reuse.
  • Offline Store: Access historical feature data for model training and backfilling, integrating with data warehouses like Google BigQuery, Snowflake, and AWS S3/Glue.
  • Online Store: Serve low-latency feature values for real-time model inference, supporting databases such as Redis, DynamoDB, and Google Cloud Datastore.
  • Point-in-Time Correctness: Ensures that features retrieved for a specific timestamp reflect the data available at that exact moment, crucial for accurate historical training and preventing data leakage.
  • Materialization: Pre-computes and caches feature values from the offline store into the online store, improving serving performance and reducing load on source systems.
  • Data Source Connectors: Provides built-in connectors for various data sources, including Apache Kafka, Google Cloud BigQuery, AWS S3, and Snowflake, allowing flexible data ingestion.
  • Monitoring and Observability: Offers mechanisms to monitor feature freshness and data quality, helping to identify and address issues in feature pipelines.
  • Version Control: Supports versioning of feature definitions, enabling collaboration and controlled evolution of features over time.

Pricing

Feast is an open-source project released under the Apache 2.0 License. It is free to use, modify, and distribute.

Product Description Pricing Model As of Date Reference
Feast Open Source Core feature store functionality for defining, managing, and serving ML features. Free (Apache 2.0 License) 2026-05-09 Feast documentation

Common integrations

Alternatives

  • Tecton: A commercial feature platform offering managed services, advanced governance, and broader enterprise capabilities built on a similar architectural foundation to Feast.
  • Hopsworks Feature Store: An open-source and managed platform providing a feature store as part of a broader MLOps ecosystem, with strong ties to Apache Flink and Spark.
  • Amazon SageMaker Feature Store: A fully managed feature store service within AWS SageMaker, integrating natively with other AWS ML services.

Getting started

To begin using Feast, you typically define your features in a feature_store.yaml file and a Python file, apply the definitions, and then retrieve features. This example demonstrates a basic setup for defining and retrieving a user's transaction count.

import pandas as pd
from datetime import datetime, timedelta

from feast import FeatureStore, Entity, FeatureView, Field, ValueType
from feast.types import Int64, Float32

# 1. Define an entity
user_entity = Entity(name="user_id", description="ID of the user", value_type=ValueType.INT64)

# 2. Define a feature view
# This example uses a simple in-memory DataFrame as a data source for demonstration
# In a real scenario, you'd connect to a data warehouse or streaming source.

# Create a sample DataFrame for the feature data
start_time = datetime.now().replace(microsecond=0, second=0, minute=0) - timedelta(days=1)
feature_df = pd.DataFrame({
    "user_id": [1001, 1002, 1003, 1004],
    "transaction_count_7d": [5, 12, 3, 8],
    "avg_transaction_amount_7d": [50.5, 25.1, 75.3, 10.2],
    "event_timestamp": [start_time + timedelta(hours=i) for i in range(4)]
})

user_transaction_fv = FeatureView(
    name="user_transaction_features",
    entities=[user_entity],
    ttl=timedelta(days=7),
    features=[
        Field(name="transaction_count_7d", dtype=Int64),
        Field(name="avg_transaction_amount_7d", dtype=Float32),
    ],
    online=True, # Enable for online serving
    description="7-day transaction features for users",
    # For a real project, you would define a real data source instead of in-memory df
    # For local testing, a file source can be used:
    # batch_source=FileSource(path="data/user_transactions.parquet", event_timestamp_column="event_timestamp"),
    # Or a more advanced SQL source:
    # batch_source=BigQuerySource(table="project.dataset.user_transactions", event_timestamp_column="event_timestamp"),
)

# 3. Create a feature_store.yaml (usually in a 'feature_repo' directory)
# (This part is typically a file, but for demonstration, we'll outline its content)
# -- Begin feature_store.yaml content --
# project: my_feature_project
# registry: data/registry.db
# provider: local
# online_store:
#     type: sqlite
#     path: data/online_store.db
# -- End feature_store.yaml content --

# 4. Initialize Feast (assuming 'feature_repo' directory with feature_store.yaml exists)
# You would run 'feast apply' from your terminal in the feature_repo directory first.
# For this example, let's simulate the application and a local store

# To run this code, first create a 'feature_repo' directory and a 'feature_store.yaml' inside it.
# Then place the Python script in the 'feature_repo' directory and run 'python your_script_name.py'.
# You would also need to simulate writing feature_df to a file (e.g., parquet) 
# that the FileSource could then read.

# For this simplified example, we'll demonstrate feature retrieval assuming definitions are applied.
# In a real scenario, you would run 'feast apply' first.

# Setup a dummy feature store for execution context (not a real persistence)
fs = FeatureStore(repo_path=".") # Points to the directory containing feature_store.yaml

# Manually adding the feature view for the sake of a runnable example 
# (normally 'feast apply' handles registration)
# This part would not be in typical Feast usage; 'feast apply' loads from files.
# We'll skip complex local file setup to make the example runnable without external file creation.

# To get a runnable example, we will focus on the retrieval part, 
# assuming features are already defined and data is available.
# Actual Feast setup would involve writing feature definitions to files and running 'feast apply'.

# Example of getting historical features for training
entity_rows = pd.DataFrame({
    "user_id": [1001, 1003],
    "event_timestamp": [datetime.now() - timedelta(hours=1), datetime.now() - timedelta(hours=2)]
})

# This part would interact with the Feast client after 'feast apply'
# For a real test, you'd need a real data source for the FeatureView.
# If you had a local parquet file 'data/user_transactions.parquet' generated from feature_df,
# and configured the FeatureView to use it, this would work.

# Simulating the feature retrieval call (conceptually)
# This specific call requires the 'user_transaction_features' to be materialized
# or for the batch_source to be properly configured and accessible.
# features_to_get = fs.get_historical_features(
#     entity_df=entity_rows,
#     features=[
#         "user_transaction_features:transaction_count_7d",
#         "user_transaction_features:avg_transaction_amount_7d",
#     ],
# ).to_df()
# print("\nHistorical Features:\n", features_to_get)

# Example of getting online features for inference
# Requires features to be materialized to the online store

# For this to work, you'd need to have run 'feast apply' and then 'feast materialize-incremental' or 'feast materialize'
# And for the online store (e.g., Redis or SQLite) to be populated.
# Let's mock a simple online retrieval assuming the store is populated

# In a real application, you'd retrieve features like this:
# online_features = fs.get_online_features(
#     entity_rows=[
#         {"user_id": 1001},
#         {"user_id": 1002},
#     ],
#     features=[
#         "user_transaction_features:transaction_count_7d",
#         "user_transaction_features:avg_transaction_amount_7d",
#     ],
# ).to_dict()
# print("\nOnline Features:\n", online_features)

print("Feast setup requires 'feature_repo' directory, feature definitions in Python files within it, and 'feast apply' command.")
print("Please refer to the official Feast documentation for a complete runnable example:")
print("https://docs.feast.dev/getting-started/quickstart")