Feature Stores Explained — Feast, Tecton, SageMaker

A feature store is the piece of infrastructure that sits between raw data and a trained model, guaranteeing that the numbers a model was trained on are computed the exact same way as the numbers it sees in production. That guarantee sounds trivial until you have watched it fail: a model that scored 0.91 AUC in validation quietly drops to 0.74 in production because a "30-day average spend" column was computed with a rolling window in a notebook and a live SQL query in the API, and the two definitions disagreed at the edges. This guide walks through what feature stores actually do, why they exist, how Feast, Tecton, and the major cloud offerings differ, and when the infrastructure is worth adopting versus when a disciplined function is enough.

---

The problem feature stores solve

Most production machine learning systems have two separate code paths that are supposed to compute the same thing. One runs offline, usually in a notebook or a batch job, and produces the training dataset. The other runs online, inside an API or a microservice, and produces the input for a live prediction. Nobody designs it that way on purpose. It happens because a data scientist writes exploratory pandas code first, and an engineer later reimplements the same logic in whatever language and framework the production service uses.

Training (offline), written by a data scientist in a notebook:

df = pd.read_csv('orders.csv')
df['avg_30d_spend'] = df.groupby('user_id')['amount'].rolling('30D').mean()
model.fit(df[features], df['churn'])

Serving (production), written independently by an engineer:

@app.route('/predict')
def predict(user_id):
    avg_spend = db.query(f"""
        SELECT AVG(amount) FROM orders
        WHERE user_id = {user_id} AND date > NOW() - INTERVAL '30 days'
    """)
    prediction = model.predict([{'avg_30d_spend': avg_spend, ...}])

Both blocks are trying to compute "average spend over the last 30 days." They will not agree. The pandas rolling window is calendar-day aligned in one timezone; the SQL query uses NOW() in whatever timezone the database server runs in. One might include the order placed exactly 30 days ago; the other might exclude it. One might silently drop nulls; the other might return zero. Individually these look like rounding errors. In aggregate, across dozens of features, they produce training/serving skew, the gap between how a model performs in validation and how it performs once it is making real predictions on real traffic.

Google's own engineering research on ML technical debt named this exact failure mode years before "feature store" was a common term, and it remains one of the most cited papers on why production ML systems degrade in ways that have nothing to do with the model architecture (Sculley et al., "Hidden Technical Debt in Machine Learning Systems," NeurIPS 2015). The paper's core argument is that the model code itself is a small fraction of a real ML system; the surrounding plumbing, including feature computation, is where the debt accumulates.

A feature store fixes this by making one thing true: there is exactly one definition of each feature, and both training and serving pull from it.

Uber's internal feature store, Palette, is part of the Michelangelo ML platform that launched in 2016. By 2022 it hosted more than 20,000 reusable features shared across teams, and the three engineers who built it went on to found Tecton, one of the two commercial feature stores discussed below ([Uber Engineering, "Palette Meta Store Journey"](https://www.uber.com/en-US/blog/palette-meta-store-journey/)).

Why this is worse than it sounds

The insidious part of training/serving skew is that it rarely throws an error. The prediction pipeline does not crash; it just produces slightly worse predictions, and slightly worse predictions are hard to distinguish from normal model drift, seasonality, or a market shift. Teams often spend weeks retraining, tuning hyperparameters, or blaming the model architecture before someone traces the gap to a feature definition mismatch. Think of it like a recipe handed to two chefs in two different kitchens: both believe they are making the same dish, but one kitchen's oven runs 15°C hot. The dish that comes out is recognizably related but never quite right, and nobody in either kitchen can see the other's oven to compare.

---

What a feature store actually does

Strip away the marketing and a feature store provides four concrete capabilities. Understanding these four is enough to evaluate whether you need one at all.

1. Feature definitions live in exactly one place

Instead of two implementations of "average 30-day spend," there is one. It is defined once, in a shared repository, and both the training pipeline and the serving pipeline call it.

from feast import FeatureView, Field
from datetime import timedelta

@feature_view(
    entities=['user_id'],
    ttl=timedelta(days=30)
)
def user_activity_features(user_data, order_data):
    return user_data.merge(order_data).agg({
        'total_orders_30d': 'count',
        'avg_spend_30d': 'mean',
        'days_since_last_order': lambda x: (datetime.now() - x.max()).days
    })

This single block of code is what both the offline training job and the online serving API call. There is no second implementation to drift out of sync.

2. Two serving modes, one source of truth

A feature store exposes the same feature definitions through two interfaces that have very different performance requirements.

Offline (training): pull a full historical DataFrame, often millions of rows, with no latency pressure.

training_df = feature_store.get_historical_features(
    entity_df=labels_df,  # has user_id and target
    features=['user_activity_features:total_orders_30d',
              'user_activity_features:avg_spend_30d']
)

Online (real-time): pull the current value for a single entity, typically inside a request that must finish in tens of milliseconds. Feast's own documentation and third-party production write-ups both cite online-store retrieval targets in the single-digit to low double-digit millisecond range when backed by an in-memory store like Redis, versus 50 to 100+ ms for less specialized online stores (Feast documentation, "Get online features").

features = feature_store.get_online_features(
    features=['user_activity_features:total_orders_30d',
              'user_activity_features:avg_spend_30d'],
    entity_rows=[{'user_id': 'abc123'}]
)

Both calls read from the same underlying feature definition. That is the entire trick.

3. Point-in-time correctness

This is the subtlest and most consequential capability, and it is the one that hand-rolled solutions almost always get wrong. When you build a training set, each row needs the feature values as they existed at the moment the label was generated, not the feature values as they exist today.

Training row: user_id=ABC, label_date=2024-06-15
              feature: avg_30d_spend

Feature store returns: avg_30d_spend as of 2024-06-15
                        (NOT today's value)

If a model is trained on today's feature values but labels from six months ago, it is effectively being shown the future: information that would not have been available at prediction time. This is called label leakage, and it is one of the most common causes of a model that looks excellent in offline evaluation and then falls apart in production, because in the real world the model never has access to future data. A feature store's point-in-time join logic (sometimes called an "as-of join") enforces the correct temporal boundary automatically, across every feature, every time a training set is built.

4. Feature reuse across models

In an organization with more than one ML model in production, the same underlying signal frequently gets reused.

Feature	Used by
user_total_orders_30d	Churn model, recommendation model, fraud model
avg_session_duration	Engagement model, churn model, personalization model
device_risk_score	Fraud model, account-takeover model

Without a shared store, each team recomputes these independently, in slightly different ways, at real infrastructure cost. With a shared store, the feature is computed once and consumed by every model that needs it, and if the definition is improved, every downstream model benefits without a separate migration.

---

The leading feature stores in 2026

Feast (open source)

Feast began as a 2018 collaboration between Gojek and Google, was open-sourced later that year, and moved under neutral governance when it joined the Linux Foundation for AI (now LF AI & Data) in 2020 (LF AI & Data, "Feast" project page). It remains the most widely adopted open-source feature store and is the default reference implementation most engineers mean when they say "feature store" in casual conversation.

Strengths:

• Free and open source, no vendor lock-in
• Works with any warehouse: BigQuery, Snowflake, Redshift, and others as offline stores
• Pure Python feature definitions, version-controllable like any other code
• Backed by production adopters including Gojek, Postmates, and Robinhood, plus a Linux Foundation governance model that survives any single company's fate

Weaknesses:

• You host the infrastructure yourself, including the online store (Redis, DynamoDB, or similar)
• Thinner UI and monitoring surface than the commercial options
• Governance, lineage, and access-control features require more manual setup

Best for: teams with real platform engineering capacity who want full control and no vendor dependency.

Tecton

Tecton was founded in 2020 by Mike Del Balso, Kevin Stumpf, and Jeremy Hermann, the three engineers who built Uber's Michelangelo and its Palette feature store. The company launched publicly with a $25 million seed and Series A co-led by Andreessen Horowitz and Sequoia in April 2020 (GlobeNewswire, "Founded by Creators of Uber Michelangelo, Tecton.ai Launches," April 2020), and raised a further $100 million Series C in 2022, bringing total funding to roughly $160 million at a reported $900 million valuation (TechCrunch, "Tecton raises $100M," July 2022). In August 2025, Databricks acquired Tecton to fold real-time feature engineering into its Lakehouse and AI-agent stack, a move Databricks framed around reducing latency for AI agent applications rather than traditional batch ML (PYMNTS, "Databricks to Purchase Tecton to Boost AI Agent Offerings," 2025). Tecton also became a core contributor to Feast itself starting in late 2020, so the two are not purely rivals; Tecton's commercial product and the open-source project share DNA (GlobeNewswire, "Tecton Becomes Feast Core Contributor," November 2020).

Strengths:

• Built by the team that solved this exact problem at Uber scale first
• Fully managed, no infrastructure to operate
• Strong observability, data-quality monitoring, and governance out of the box
• Purpose-built for low-latency, high-throughput real-time feature engineering
• Now backed by Databricks' distribution and Lakehouse integration post-acquisition

Weaknesses:

• Enterprise pricing, meaningfully more expensive than self-hosting
• Vendor lock-in, now specifically to the Databricks ecosystem
• Overkill for teams without genuine real-time, high-scale requirements

Best for: organizations with serious real-time ML stakes, particularly ones already standardized on Databricks.

AWS SageMaker Feature Store

Amazon's managed offering, integrated directly with the rest of SageMaker's training and inference stack. It exposes both an offline store (backed by S3 and queryable via Athena) and an online store designed for low-latency lookups.

Strengths:

• Zero infrastructure to manage
• Tight integration with SageMaker Pipelines, training jobs, and endpoints
• Pay-per-use pricing model, no fixed enterprise contract

Weaknesses:

• Locked to AWS
• Less flexible feature-definition language than Feast or Tecton
• Fewer advanced monitoring and lineage capabilities than dedicated tools

Best for: teams already committed to SageMaker for the rest of their ML lifecycle.

Google Vertex AI Feature Store

Google Cloud's equivalent, tightly integrated with BigQuery as the offline source and Vertex AI's training and prediction services. The value proposition mirrors SageMaker's: convenience for teams already inside the GCP ecosystem, with the same tradeoff of cloud lock-in.

Databricks Feature Store (now including Tecton)

Native to Databricks' Lakehouse architecture and Delta Lake, this option makes the most sense for teams whose data already lives in Databricks. Post-acquisition, expect Tecton's real-time engineering capabilities to be progressively folded into this product line rather than remaining a fully separate offering.

Hopsworks

A smaller but notable open-source and managed feature store, originally built at KTH Royal Institute of Technology in Sweden and now maintained by Hopsworks AB. It is worth a look for teams that want an open-source alternative to Feast with a stronger built-in UI and a hosted managed tier, particularly in Europe.

---

When you actually need a feature store

Feature stores solve a real problem, but the real problem only exists past a certain scale. Below that scale, the infrastructure is pure overhead: something else to deploy, monitor, and pay for, without a corresponding win.

You probably need one if:

• You have three or more ML models in production sharing overlapping input data
• Multiple teams are independently recomputing similar features
• You have genuine online, real-time serving requirements (sub-100ms predictions on live traffic)
• You have already been burned by a training/serving skew bug and traced it to duplicated feature logic
• You operate in a regulated industry where feature lineage and auditability are compliance requirements, not nice-to-haves

You probably don't need one yet if:

• You have one model in production
• All predictions are batch, run on a schedule, with no real-time serving path
• Your ML team is one to three people
• Your current "pandas plus a database query" approach has not caused a production incident

Chip Huyen's widely read book on production ML systems design makes a version of this same point directly: infrastructure like feature stores should be adopted in response to a demonstrated organizational pain point, not adopted speculatively because a company blog post made it sound necessary (Huyen, Designing Machine Learning Systems, O'Reilly, 2022). The discipline of "one function, one definition, used everywhere" matters more than which specific tool enforces it.

---

A minimal Feast example, end to end

This is close to the smallest complete Feast setup that demonstrates all four core capabilities above: a defined entity, a feature view backed by a real data source, an offline training pull, and an online serving pull.

# pip install feast

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

# 1. Define the entity — the thing features describe
user = Entity(
    name='user_id',
    join_keys=['user_id'],
    description='Unique user identifier'
)

# 2. Point at a data source
user_orders = FileSource(
    path='data/user_orders.parquet',
    timestamp_field='order_date',
)

# 3. Define the feature view — this is the single source of truth
user_features = FeatureView(
    name='user_features',
    entities=[user],
    ttl=timedelta(days=365),
    schema=[
        Field(name='total_orders_30d', dtype=Int64),
        Field(name='avg_spend_30d', dtype=Float64),
        Field(name='days_since_last_order', dtype=Int64),
    ],
    source=user_orders,
)

# 4. Apply the definitions to the store
fs = FeatureStore(repo_path='.')
fs.apply([user, user_features])

# 5. Materialize features into the online store for low-latency lookups
fs.materialize_incremental(datetime.now())

# 6. Training: pull historical, point-in-time-correct features
training_df = fs.get_historical_features(
    entity_df=labels_df,
    features=['user_features:total_orders_30d', 'user_features:avg_spend_30d']
).to_df()

# 7. Serving: pull current features for one user, low latency
online_features = fs.get_online_features(
    features=['user_features:total_orders_30d'],
    entity_rows=[{'user_id': 'abc123'}]
).to_dict()

The important part is step 3. Everything downstream, training and serving alike, reads from that one definition. Change the aggregation logic once, in one place, and both paths update together.

---

Alternative: discipline without tooling

Not every team is ready to operate a feature store, and not every team needs one. It is entirely possible to get most of the training/serving skew protection with nothing more than a shared function and a team convention that both pipelines must import it.

# features.py — single source of truth, no infrastructure required
def compute_user_features(user_id, as_of_date):
    """Used in both training and serving. Never duplicated."""
    return {
        'avg_30d_spend': db.query(f"""
            SELECT AVG(amount) FROM orders
            WHERE user_id = '{user_id}'
            AND date BETWEEN '{as_of_date}'::date - INTERVAL '30 days'
            AND '{as_of_date}'
        """).fetchone()[0],
        # ...more features
    }

# Training
training_features = pd.DataFrame([
    compute_user_features(uid, dt)
    for uid, dt in zip(user_ids, dates)
])

# Serving
@app.route('/predict')
def predict(user_id):
    features = compute_user_features(user_id, datetime.now())
    return model.predict([features])

One function, imported by both code paths, is not a feature store, but it eliminates the specific failure mode this entire article is about: two independent implementations of the same feature quietly drifting apart. Point-in-time correctness across a large historical backfill and sub-50ms online serving at scale are where hand-rolled discipline eventually runs out of road, but plenty of teams never reach that point.

What people get wrong about "just build it yourself"

The most common mistake is underestimating point-in-time correctness. It is easy to write a function that returns the "right" feature value today and assume that same function is safe to reuse across a year of historical training labels. It usually is not, because most naive implementations quietly use NOW() or the current table state rather than the state as of each historical label date. This produces label leakage that inflates offline metrics and never shows up until the model underperforms in production. If your hand-rolled system trains on more than a few weeks of historical labels, point-in-time correctness needs to be handled explicitly, whether that means a feature store or a carefully engineered as-of join in your own SQL.

---

Real-world example: DoorDash's real-time feature framework

DoorDash's engineering team has published detailed accounts of building and iterating on their internal feature infrastructure, which illustrates why real-time feature engineering gets harder as scale increases. Their "Riviera" framework, built on Apache Flink, lets data scientists declaratively specify feature transformations from raw event streams to the feature store rather than hand-writing low-level stream-processing code for every new feature (DoorDash Engineering, "Building A Declarative Real-Time Feature Engineering Framework"). In a separate post, the same team documented a 70% latency improvement to their online feature store by adding client-side caching, a concrete illustration of how much engineering effort goes into keeping online feature retrieval fast once a company operates at real-time, high-throughput scale (DoorDash Engineering, "How We Applied Client-Side Caching to Improve Feature Store Performance by 70%"). This is the kind of infrastructure investment that only makes sense once you are well past the "one model, batch predictions" stage described above.

---

Performance considerations

Your online serving requirements are the single biggest driver of how much complexity you actually need.

Batch only, no live requests: Pandas plus scheduled database queries work fine. There is no latency budget to protect, so there is no reason to add an online store at all.

Real-time, low volume (roughly under 1 request per second): You need some kind of online store, but a lightweight setup, Redis or DynamoDB behind a thin API, is usually sufficient without adopting a full feature store platform.

Real-time, high scale (hundreds to thousands of requests per second): This is where dedicated feature store infrastructure like Tecton, Databricks Feature Store, or a heavily optimized self-hosted Feast deployment earns its cost. DoorDash's caching case study above is a good illustration of the kind of tuning that becomes necessary at this tier.

---

Cost comparison

Table: Feature store options by monthly cost and setup time (2026).

Option	Approximate monthly cost	Setup time
Manual (shared function + database)	$0	About 1 day
Feast, self-hosted	$50–$500 (infrastructure only)	1–2 weeks
AWS SageMaker Feature Store	$200–$2,000	2–4 days
Google Vertex AI Feature Store	$200–$2,000	2–4 days
Tecton (now via Databricks)	$5,000–$50,000+	1–3 months
Databricks Feature Store	Bundled with Databricks platform spend	1–2 weeks
Hopsworks (managed)	Varies, generally below Tecton's tier	1–2 weeks

These figures are directional, drawn from typical published pricing tiers and infrastructure sizing rather than a fixed quote, since actual cost depends heavily on data volume, request throughput, and negotiated enterprise contracts. Tecton's enterprise pricing is real and appropriate for organizations with genuine real-time ML at scale; for most teams, Feast or manual discipline is enough.

---

Common confusions and what people get wrong

"A feature store is the same thing as a data warehouse." A data warehouse stores raw or lightly transformed data for analytics. A feature store specifically manages ML features: it adds point-in-time correctness, an online low-latency serving path, and cross-model reuse, none of which a warehouse provides on its own. Many feature stores, including Feast and SageMaker Feature Store, read their offline data directly from a warehouse. The warehouse is the source; the feature store is the discipline layer on top of it.

"We need a feature store because we have a lot of data." Data volume alone is not the trigger. A single model consuming a huge table has no training/serving skew problem, because there is only one pipeline. The trigger is having two independently maintained code paths, or multiple models needing the same feature, not raw data size.

"Adopting Feast solves training/serving skew automatically." Adopting the tool is necessary but not sufficient. Teams still need to actually delete the duplicated legacy feature logic and route both training and serving through the new definitions. It is common to see organizations stand up a feature store and then leave an old ad hoc pipeline running in parallel "just in case," which recreates exactly the problem the tool was meant to solve.

"Feature stores are only for tabular ML." The concept originated in tabular, aggregation-heavy use cases (churn, fraud, recommendations), but the same point-in-time-correctness and skew problems apply to embeddings and retrieval features used in modern retrieval-augmented generation and agent pipelines, which is part of why Databricks explicitly framed its 2025 Tecton acquisition around AI agents rather than classic tabular ML.

---

FAQ

Q: Do I need a feature store for my first ML model? A: No. Build the model, get it into production, and see whether feature duplication or skew actually becomes a problem before adding infrastructure to prevent a problem you have not encountered yet.

Q: What's the difference between a feature store and a data warehouse? A: A data warehouse stores raw or transformed data broadly. A feature store specifically manages ML features with point-in-time correctness, low-latency online serving, and reuse across models, and it typically reads its raw data from a warehouse rather than replacing it.

Q: Can I build my own feature store instead of using Feast or Tecton? A: You can, but it is rarely worth it. Feast covers the large majority of common use cases for free, and Tecton exists specifically for the teams that outgrow Feast's operational demands. Build a custom system only for very specific requirements neither option can meet.

Q: Feature store vs. MLOps platform, what's the difference? A: A feature store handles features specifically. MLOps platforms like MLflow and Kubeflow handle the broader lifecycle: experiment tracking, model registry, and deployment. Many MLOps platforms integrate with or embed a feature store rather than replacing the need for one. See MLOps Explained for Beginners for the broader picture.

Q: What is training/serving skew, exactly? A: It is the gap between a model's offline evaluation performance and its live production performance, caused by the training pipeline and the serving pipeline computing the same nominal feature in subtly different ways. It is one of the most common and hardest-to-diagnose production ML bugs because it produces no error, only degraded accuracy.

Q: What is point-in-time correctness and why does it matter so much? A: It means that when you build a training set, each row's features reflect what was true at that row's label date, not today's values. Getting this wrong leaks future information into training, inflating offline metrics on data the model would never actually have access to in production.

Q: Is Feast still actively maintained after Tecton's acquisition by Databricks? A: Yes. Feast is governed by LF AI & Data, not by any single company, and its contributor base spans multiple organizations beyond Tecton, so the open-source project's governance does not depend on Tecton's corporate ownership.

Q: How does a feature store fit into an AI agent or RAG pipeline? A: Agent and retrieval-augmented pipelines need low-latency, freshness-sensitive context (user state, recent interactions, embeddings) at inference time, which is functionally the same online-serving problem feature stores were built to solve for tabular ML. Databricks' rationale for acquiring Tecton in 2025 was explicitly to bring that infrastructure into its AI agent stack.

Q: What's the single best starting point if I've decided I need one? A: For most teams in 2026, start with Feast, since it is free, well documented, and portable across warehouses. Only evaluate Tecton, SageMaker, or Vertex AI Feature Store once Feast's operational overhead genuinely outweighs its cost advantage, typically once you need managed low-latency serving at real production scale.

Q: Where can I learn more? A: Feast's own documentation (docs.feast.dev) is the best hands-on starting point. Chip Huyen's Designing Machine Learning Systems (O'Reilly, 2022) covers the underlying production ML design problem in depth, and Uber's and DoorDash's public engineering blogs document real production feature-infrastructure decisions at scale.

---

Related Articles

• MLOps Explained for Beginners
• Best Data Science Tools 2026
• ML Engineer Career Path 2026
• Cloud Platforms for Data Science

---

The takeaway

A feature store is not a universal requirement, it is a response to a specific, well-documented failure mode: two independently maintained implementations of the same ML feature drifting apart until a model's production accuracy quietly falls below its offline evaluation. If you have one model, batch predictions, and a small team, a shared function and a team convention will get you most of the protection for zero infrastructure cost. Once you have multiple models sharing signals, genuine real-time latency requirements, or compliance demands around feature lineage, the calculus flips, and Feast, Tecton (now inside Databricks), or your cloud provider's managed offering earns its keep by turning an implicit, error-prone agreement between two teams into an explicit, enforced one.

Last verified: July 2026