A centralized platform for storing, managing, and serving ML features — ensuring consistency between model training and real-time inference.
Feature stores are one of those topics where the hype has cooled off and the actual architectures have matured. In 2019-2021, every ML team was scrambling to stand up Feast or Tecton. Around 2023 a lot of teams realized: unless you have real-time inference with online feature requirements, you may not need a "feature store" as a distinct piece of infrastructure — you need a shared feature registry and consistent batch-time feature computation. Which is mostly just dbt or SQL views in your warehouse, plus a thin layer for online lookup.
Every ML platform that grows past ~5 models hits the same two pains: (1) training-serving skew — the features you trained on aren't exactly the features you're scoring on, and the model quietly underperforms in prod; (2) feature duplication — three teams all compute "user 30-day purchase count" slightly differently and silently ship three different versions. A feature store fixes both by being the single source of truth for feature logic, with the same definition running at training time (against historical data) and serving time (against current data).
At one company the ML team wanted Tecton — beautiful product, strong feature; about $90K/year. We ended up shipping a simpler solution: (1) all features defined as dbt models in Snowflake (offline store); (2) nightly Snowpipe Streaming into a small Redis cluster for the ~40 features we actually needed online (online store); (3) a tiny Python SDK that both trainers and the inference service imported to compute derived features consistently. Cost: < $2K/year total. Is it as sophisticated as Tecton? No — no point-in-time correctness tooling, no backfill UI, no lineage graphs. Did it solve the real problem (training-serving skew for our model lineup)? Yes. When to actually pay for a managed feature store: when you're running 50+ models, have streaming features with strict point-in-time requirements, or have a dedicated ML platform team that can drive the integration.
A Feature Store is a centralized repository for storing, versioning, and serving machine learning features. It bridges the gap between data engineering and ML engineering by providing a single source of truth for feature definitions, ensuring that the features used during model training are identical to those used during real-time inference.
Without Feature Store:
Training: SQL query → Pandas → feature engineering → model.fit()
Serving: API request → different code → different features → SKEW!
With Feature Store:
Training: feature_store.get_historical('user_features') → model.fit()
Serving: feature_store.get_online('user_features') → model.predict()
Result: SAME features, ZERO skew| Tool | Type | Best For |
|---|---|---|
| Feast | Open Source | Simple, flexible, Kubernetes-native |
| Tecton | Managed | Enterprise real-time ML |
| Databricks Feature Store | Integrated | Databricks/MLflow users |
| SageMaker Feature Store | Managed | AWS-native ML workflows |
| Hopsworks | Open Source | Feature pipelines + serving |
| Snowflake (Cortex) | Integrated | Snowflake-native ML |
Things teams underestimate when adopting a feature store:
A feature store is a centralized platform for storing, versioning, and serving machine learning features — the transformed variables that go into ML models. It makes feature definitions a shared, reviewable artifact (instead of scattered notebook code) and ensures the same feature logic runs for both training (against historical data) and real-time inference (against current data). Popular implementations: Feast (open source), Tecton, Databricks Feature Store, SageMaker Feature Store, Hopsworks. The conceptual split is an offline store (warehouse-resident, batch access for training) and an online store (low-latency key-value for serving).
Three reasons: (1) training-serving skew — when features are computed in a notebook at training time and re-implemented in a microservice at serving time, the two drift apart and the model silently degrades in production; (2) feature duplication — multiple teams reinvent "user 30-day purchase count" with slightly different definitions; (3) discoverability — without a central catalog, nobody knows what features already exist, so they're rebuilt. A feature store gives one definition that serves both sides and a registry everyone searches. That said, not every ML team needs one — the bar is usually 5+ models in production with shared features, or real-time inference requirements.
The offline store holds historical feature values for training — typically a data warehouse (Snowflake, BigQuery) or data lake (S3 + Iceberg/Delta). Queries against it are batch-scale and need to support point-in-time joins so the training set reflects "what was known at prediction time." The online store holds the latest feature values for real-time inference — typically a low-latency key-value database (Redis, DynamoDB, Bigtable) with <10ms single-key reads. A feature store's job is to keep these two in sync: the same feature logic populates both, so models see the same values at training and at serving time.
Training-serving skew happens when the features a model was trained on differ from the features it sees at inference time, causing silent quality degradation. Common causes: (1) SQL transformations in training that don't match the code path at serving (rounding differences, join differences); (2) stale online feature values; (3) schema drift in upstream data; (4) data leakage at training where future information bleeds into historical features. Feature stores reduce skew by enforcing a single feature definition that runs against both offline and online data, but they don't eliminate it — you still need monitoring (feature distribution checks, serving logs) to catch drift when it happens.
Feast is open source and lightweight — you provide the infra (warehouse + Redis/DynamoDB) and run Feast as a thin layer. Best for teams that want OSS and have platform capacity. Tecton is a fully managed commercial service — strongest at streaming features, point-in-time correctness, and complex transformations; pricey but reduces ops burden. Databricks Feature Store (now part of Unity Catalog) is free with Databricks and integrates with MLflow and Unity governance; best if you're Databricks-native. SageMaker Feature Store is the AWS-native option, tightly integrated with SageMaker pipelines. If you're Snowflake-native, Feast with Snowflake as offline store + your choice of online store (or SPCS-hosted Redis) is a common pattern.
Probably not — at least not a dedicated one. If all your inference runs as batch jobs (e.g., nightly scoring), you can usually get the same benefits from disciplined dbt modeling: features defined as dbt models, a clear naming convention and tagging scheme, proper tests for point-in-time correctness, and a shared feature catalog in dbt docs. You skip the online store and the feature-serving infrastructure entirely. The moment you add real-time inference or cross-team feature reuse becomes a pain, revisit the decision. Batch-only ML teams that adopt a full feature store often find it over-engineered for what they need.
Yes, and many teams do. Snowflake as offline store is natural — it's already where your data lives, dbt models are your feature definitions, and time travel helps with point-in-time correctness. For the online store, you either (a) use Snowflake Hybrid Tables for low-latency key-value access, (b) sync features to Redis/DynamoDB via Snowpipe Streaming or a CDC pipeline, or (c) for applications that can tolerate ~100-500ms lookups, query Snowflake directly. Snowflake ML Feature Store (in the Cortex family) is becoming a first-party option that encapsulates this pattern. For many Snowflake-native teams, this beats standing up a separate feature store product.