Teams often rebuild the same feature calculations in multiple places, which wastes time and creates inconsistencies. Training data may differ from production data, so models learn patterns that do not exist in real usage. As a result, models can fail because the features used during live predictions do not match the features used during training.In early machine learning workflows, data scientists often created features inside notebooks using SQL, Python, or spreadsheets. A churn model might use customer lifetime value, transaction counts, login frequency, and support ticket history. While experimentation may succeed, production deployment introduces harder problems.
For example, a bank may define customer age differently in training and production. In training, age is calculated as 2024 - birth_year, but in production it is calculated using the exact birthdate. This creates inconsistent inputs.
Suppose a loan model was trained using customers with age = 30, but in production the same customer becomes age = 29 because of a different formula. The model now receives different values than it learned from, which can reduce prediction accuracy.
Similarly, if training uses monthly income in dollars but production sends annual income, the model may fail because live features do not match training features.
Engineering teams must rebuild those same features in real time. Logic written for training may differ from logic written for serving. Historical backfills become difficult. Different teams duplicate work. Governance becomes weak because nobody knows which features already exist or who owns them.
This creates training-serving skew, wasted effort, inconsistent definitions, and slow deployment cycles. Feature stores emerged as the operational solution.
A feature store is a centralized system for defining, storing, computing, sharing, and serving machine learning features consistently across training and inference environments. Instead of every team independently rebuilding feature pipelines, a feature store creates reusable and governed feature assets. Among the best-known tools in this space are Feast and Tecton.
This article explains feature stores practically, why they matter, how they work, and how Feast and Tecton are used in production systems.
What a Feature Store Does
A feature store acts as a managed layer between raw data systems and machine learning models. It defines feature transformations once and makes them available consistently for both offline model training and online predictions.It usually contains an offline store for historical analytics and training datasets, plus an online store optimized for low-latency serving during real-time inference. It also includes metadata such as feature owners, freshness, lineage, documentation, and quality rules.
In practical terms, it turns raw columns and event streams into reliable model-ready inputs.
Consider a fraud detection model. Useful features may include number of transactions in the last hour, average purchase value over seven days, device change frequency, failed login attempts, and distance from usual location.
Without a feature store, separate teams may compute these differently for training and production. With a feature store, the feature definitions are standardized and reused everywhere.
The offline store contains historical feature values used for training, validation, and experimentation. It may sit on warehouses or lakehouses such as BigQuery, Snowflake, Redshift, or Spark-based storage.
The online store serves the latest feature values quickly during prediction requests. It often uses low-latency systems such as Redis, DynamoDB, Cassandra, or managed key-value databases.
This separation exists because training workloads and serving workloads have very different performance needs.
One of the most important ideas in feature stores is point-in-time correctness. When training a model using past records, features must reflect only information available at that historical moment. Future data leakage creates unrealistically strong models that fail in production.What is Actually Stored?
A feature store does not store the model itself, and it does not store raw logs directly. Instead, it stores processed input variables that machine learning models use for predictions. These processed variables are called features.
For example, in a fraud detection system, stored features may include customer_id = 101, avg_transaction_30d = 4200, transactions_last_1h = 5, chargebacks_last_90d = 1, and device_risk_score = 0.82. These values summarize customer behavior and risk signals in a format that models can directly use.When Are They Stored?
1. Batch / Scheduled Updates → Offline Store
Many features are generated in scheduled batch jobs that run every hour or every day. A data pipeline reads raw sources such as transaction tables, click logs, orders, and payment records, then transforms them into reusable features such as avg_spend_30d, orders_last_7d, and refund_rate.
These features are usually saved into an offline store such as S3, a data warehouse, or a data lake. They are later used for model training, backtesting, historical analysis, and analytics workloads.2. Real-Time Updates → Online Store
Some features must be updated immediately when live events happen. For example, when a user logs in, makes a payment, or clicks an ad, the system may instantly update values inside an online store such as Redis.
Examples include user_101:last_login_minutes = 0 or user_101:transactions_last_1h = 6. These real-time values are used instantly by prediction APIs that need responses in milliseconds.How Is It Used?
1. During Training
During model development, data scientists query the offline store to retrieve historical features from a time period such as January to March, along with labels such as fraud or non-fraud outcomes. This dataset is then used to train machine learning models.2. During Live Prediction
During production use, when a customer performs an action such as making a payment, the model requests the latest features from the online store. It may fetch values such as avg_transaction_30d, transactions_last_1h, and device_risk_score, then predict fraud risk in milliseconds.
Training requires large amounts of historical data, while production systems require fast current data. That is why both stores are used together. S3 is cheap, scalable, and slower, while Redis is smaller, more expensive, and extremely fast.
Feature stores help generate historically accurate training sets so model evaluation remains trustworthy.
Future data leakage happens when a model is trained using information that would not have been available at prediction time. This gives the model unfair knowledge from the future and leads to unrealistically high performance during training or validation.
For example, using next month's sales data to predict today's demand is future data leakage.
What is Feast?
Feast is an open-source feature store widely adopted for practical machine learning workflows. It allows teams to define features declaratively, materialize them into online stores, and retrieve them consistently for training and serving.Feast integrates with multiple storage systems and is popular among teams seeking flexibility without full vendor lock-in.
A common workflow in Feast is to define entities and feature views in Python, then serve those features online for real-time ML predictions.
from datetime import datetime, timedelta
from feast import Entity, FeatureStore, FeatureView, Field
from feast.types import Float32
# Entity = primary business object
customer = Entity(
name="customer_id",
join_keys=["customer_id"]
)
# FeatureView = group of features for that entity
customer_features = FeatureView(
name="customer_features",
entities=[customer],
ttl=timedelta(days=1),
schema=[
Field(name="avg_spend_30d", dtype=Float32),
Field(name="txn_count_7d", dtype=Float32),
],
)
# Connect to Feast repo
store = FeatureStore(repo_path=".")
# Apply definitions (entity + feature view)
store.apply([customer, customer_features])
# Store latest feature values from offline source
# into online store (for example Redis)
store.materialize_incremental(end_date=datetime.now())
print("Features stored successfully in the online store.")
- avg_spend_30d → average spend in the last 30 days
- txn_count_7d → number of transactions in the last 7 days
These features are typically computed in batch pipelines, then materialized into Feast's online store for fast serving.
During model inference, the latest feature values can be retrieved instantly:
from feast import FeatureStore
# Connect to Feast repository
store = FeatureStore(repo_path=".")
# Retrieve online features for customer_id = 101
features = store.get_online_features(
features=[
"customer_features:avg_spend_30d",
"customer_features:txn_count_7d",
],
entity_rows=[
{"customer_id": 101}
]
).to_dict()
print(features)
Possible output:
{
"customer_id": [101],
"avg_spend_30d": [4200.0],
"txn_count_7d": [12.0]
}
Model inference is the process of using a trained machine learning model to make predictions on new, unseen data.These values can be passed directly into a live prediction model:
For example, after training a fraud detection model, giving it a new transaction and receiving a fraud risk score is called inference.
# Prepare model input
X = [[
features["avg_spend_30d"][0],
features["txn_count_7d"][0]
]]
# Load trained model
model = joblib.load("fraud_model.pkl")
# Live prediction
prediction = model.predict(X)[0]
probability = model.predict_proba(X)[0][1]
print("Prediction:", prediction)
print("Fraud Probability:", probability)
What is Tecton?
Tecton is a managed enterprise feature platform built to operationalize machine learning at scale. It helps teams define, compute, store, monitor, and serve features consistently for both training and production inference.Tecton is widely used by organizations running large real-time ML systems such as fraud detection, recommendations, risk scoring, and personalization. It provides a production-ready feature store with strong support for governance, monitoring, batch pipelines, and streaming features.
Unlike lighter open-source solutions, Tecton focuses heavily on enterprise reliability, collaboration, and large-scale production deployments.
A common workflow in Tecton is to define entities and feature views in Python, then materialize those features into offline and online stores for training and low-latency serving.
from tecton import Entity, batch_feature_view
from tecton.types import Float64
from datetime import timedelta
# Entity = business object
customer = Entity(
name="customer_id",
join_keys=["customer_id"]
)
# Batch Feature View
@batch_feature_view(
entities=[customer],
ttl=timedelta(days=1),
online=True,
schema={
"avg_spend_30d": Float64,
"txn_count_7d": Float64,
}
)
def customer_features(df):
return df
- avg_spend_30d → average spend in the last 30 days
- txn_count_7d → number of transactions in the last 7 days
These features are typically computed from batch pipelines or streaming sources, then materialized into Tecton's online store for fast serving and into offline storage for model training.
During model inference, the latest feature values can be retrieved instantly:
workspace = tecton.get_workspace("prod")
feature_service = workspace.get_feature_service("fraud_features")
features = feature_service.get_online_features(
join_key_map={"customer_id": 101}
).to_dict()
print(features)
Possible Output:
{
"customer_id": 101,
"avg_spend_30d": 4200.0,
"txn_count_7d": 12.0
}
# Prepare model input
X = [[
features["avg_spend_30d"],
features["txn_count_7d"]
]]
# Load trained model
model = joblib.load("fraud_model.pkl")
# Live prediction
prediction = model.predict(X)[0]
probability = model.predict_proba(X)[0][1]
print("Prediction:", prediction)
print("Fraud Probability:", probability)
Conclusion
Feature stores solve one of the most persistent problems in machine learning: turning raw data into consistent, reusable, production-ready model inputs. Feast provides an open and flexible path, while Tecton offers an enterprise-grade managed platform.As machine learning systems grow, models may come and go, but trusted features remain foundational assets. Organizations that manage features well often deploy models faster, more reliably, and with far greater confidence.
Join the discussion