A feature store is a system that computes, stores, and serves ML features consistently for both model training (batch) and online inference (low-latency).
A feature store centralizes the computation and serving of ML features so that the same feature definition produces the same values whether a model is being trained on last year's data or scored in production milliseconds after a user event. The two-store architecture — an offline store (usually a data warehouse or object storage, optimized for large historical reads) and an online store (usually a low-latency KV store, optimized for point lookups) — is designed to eliminate the class of bugs where a model trains on one definition of a feature and scores against another. Feature stores also enable reuse: a feature computed once (say, 'user's last-30-day purchase count') can serve many models rather than being reimplemented per team.
(1) Training/serving skew — the leading cause of models that look great in offline eval and mysteriously underperform in production. A feature store makes the transformation logic single-sourced, so batch and online use identical code. (2) Feature reuse across teams — instead of every model re-implementing 'is this user a paying customer,' the definition lives once and multiple models consume it. (3) Backfills and point-in-time correctness — computing features 'as of' a historical timestamp for training without leakage of future information. (4) Feature freshness observability — knowing when a feature pipeline broke and stopped updating, before a model consumes stale data.
Fewer than 3-5 production models: the coordination overhead outweighs benefits. Models that all consume batch predictions (no online serving): the offline store is just your data warehouse; a full feature store is overkill. Small feature surface (dozens, not hundreds of features): a well-organized dbt project plus a Redis cache achieves 80% of the benefit with 10% of the operational load. Prototyping and R&D: adds friction to experimentation without paying back until models are production-bound.
Buy (Tecton, Databricks Feature Store, SageMaker Feature Store, Vertex AI Feature Store): fastest to production, tight cloud integration, ongoing spend that scales with usage. Sensible for teams whose bottleneck is not infrastructure but shipping models. Open source (Feast, Hopsworks): more control, less lock-in, more operational burden. Feast in particular is deliberately lightweight and pairs well with your existing warehouse + KV store. Build: reserved for orgs whose scale, latency, or compliance requirements exceed vendor capabilities. Almost always the wrong answer for the first two years.
A feature store only works if data scientists actually use it for training, not just as a serving layer glued on late. The adoption arc: (1) migrate an existing model's feature pipeline into the store, prove training/serving parity, ship. (2) new models default to the store; opt-out requires justification. (3) audit teams that keep bypassing and understand why (usually: painful DX, missing feature types, review latency for new feature definitions). Fix the DX rather than mandating usage. A feature store nobody uses because it's slower than a notebook is worse than no feature store.
Feature pipeline SLAs are now user-facing SLAs — if a feature is stale, an online model may score using yesterday's value. Monitor freshness per feature, alert on breaches. Cost management: online stores (DynamoDB, Redis, Cassandra) can become surprisingly expensive at scale; audit unused features quarterly and retire them (feature stores accumulate dead features aggressively). Governance: PII-classified features need access controls at the store layer; document lineage from source data to feature to model to prediction for audit trails. Backup and disaster recovery: treat the online store like production infra — restore drills, replication, capacity planning.
Investor directory · Fundraising library · Articles A–Z · Company funding database