Feature Store
A feature store is infrastructure that centralizes the management and serving of ML features — the computed variables that models learn from. It solves a specific problem: without a feature store, data scientists recompute the same features independently, use different definitions across models, and face training-serving skew that silently degrades production accuracy.
Feature stores emerged because organizations scaling beyond a handful of models kept hitting the same bottleneck. Building features is expensive. Rebuilding the same features across teams is wasteful. And serving features consistently in production is a different engineering problem entirely from computing them for training.
A feature store centralizes ML features so they are computed once, documented, and served consistently for both training and real-time inference. It solves three problems: duplication (teams rebuilding the same features), inconsistency (training features computed differently from serving features), and discoverability (no one knows which features already exist). Feature stores include an offline store for batch training, an online store for low-latency serving, and a registry for metadata and governance.
The Problem Feature Stores Solve
Three data science teams at a bank each compute "customer_lifetime_value" for their models. One uses 12-month revenue. Another uses 24-month revenue minus support costs. A third uses a predictive model that estimates future revenue. When the fraud team discovers that CLV correlates with fraud risk, they face a question: which version of CLV should they use? They don't even know three versions exist.
This is not a hypothetical. At any organization running more than a dozen ML models, feature duplication and inconsistency are the default state. Data scientists spend 60-80% of their time on feature engineering, and much of that time is spent rebuilding features that another team already computed — slightly differently, from slightly different source data, with slightly different definitions.
A feature store eliminates this chaos by providing one place to define, compute, store, and serve features. When the fraud team needs CLV, they browse the feature registry, find the canonical version, and use it. No duplication. No ambiguity. No silent inconsistencies across models.
Feature Store Architecture
A feature store has four components, each solving a distinct problem in the feature lifecycle.
The feature registry is the catalog. It stores metadata about every feature: its definition, who owns it, what source data it depends on, which models consume it, and quality metrics. Data scientists browse the registry to discover existing features before building new ones.
The offline store holds historical feature values used for model training. When a data scientist needs "average order value over the last 30 days for every customer, as of each day in 2025," the offline store provides point-in-time correct values. This prevents data leakage by ensuring training data reflects only what was known at each historical moment.
The online store serves features at low latency for real-time inference. When a fraud detection model needs to score a transaction in under 100 milliseconds, the online store provides pre-computed features (account age, transaction velocity, average amount) from a key-value store like Redis or DynamoDB.
The feature pipelines keep both stores current. Batch pipelines compute features on a schedule (hourly, daily). Streaming pipelines update features in near real-time from event streams. The same computation logic powers both paths — which is exactly how training-serving consistency is maintained.
Uber built Michelangelo's feature store after discovering that data scientists spent 60-80% of their time on feature engineering, much of it duplicating work already done by other teams. Centralizing features cut time-to-production for new models from months to weeks.
— Hermann & Del Balso, Meet Michelangelo: Uber's Machine Learning Platform
Training-Serving Consistency
Training-serving skew is the most insidious bug in production ML. It happens when features are computed differently during training than during inference — and it is silent. The model does not throw an error. It just makes worse predictions.
A concrete example: a model is trained with a feature avg_transaction_amount_7d computed in PySpark using a calendar-week window (Monday to Sunday). The serving pipeline computes the same feature using a rolling 7-day window starting from the current timestamp. The math is different. The values are different. The model's accuracy drops, and no alert fires because the feature values are still numbers in the expected range.
Feature stores solve this by using identical computation logic for both the offline path (training) and the online path (serving). The feature is defined once — its transformation SQL, its windowing logic, its aggregation method — and both stores are populated from that single definition. When the definition changes, both paths update together.
This is not just a technical convenience. Organizations that have debugged a model performance regression for weeks, only to discover that a serving pipeline was computing a feature differently from training, understand why training-serving consistency is the single most valuable property a feature store provides.
Real-World Use Cases
Real-time fraud detection. A payment processor needs to score every transaction in under 100 milliseconds. The fraud model requires features like user transaction history (count and total in the last hour, day, week), account age, device fingerprint frequency, and distance from the user's typical location. The online store serves these pre-computed features instantly. The offline store provides historical feature values for retraining the model weekly on labeled fraud cases.
Recommendation engines. A streaming platform maintains user preference vectors, item embeddings, and contextual features (time of day, device type, recently watched genres) in its feature store. As users browse, the online store serves updated preference vectors that incorporate the latest watch and skip signals. Dozens of recommendation models share these features — search ranking, homepage suggestions, "because you watched" carousels — all reading from the same store.
Credit decisioning. A lender serves pre-computed risk features — debt-to-income ratio, payment history score, credit utilization, employment stability index — consistently across automated underwriting and manual review paths. Whether a loan application is scored by the ML model or reviewed by a human analyst, both see the same feature values. This consistency is not just operationally useful; it is a regulatory requirement in many jurisdictions.
At Spotify, the feature store serves over 5,000 features to dozens of ML models powering recommendations, search ranking, and ad targeting. Features computed once are reused across teams, eliminating months of duplicated engineering work.
— Spotify Engineering, ML Home: Spotify's Machine Learning Platform
Platforms and Tools
Open source — Feast. Lightweight, Kubernetes-native feature store focused on serving. Feast manages the online/offline store interface and feature registry but does not include its own compute engine — teams bring their own Spark, BigQuery, or Redshift for feature computation. Best for organizations that already have data infrastructure and want a feature serving layer without lock-in.
Open source — Hopsworks. Full-platform feature store with built-in feature engineering, versioning, and monitoring. Includes a feature pipeline engine, which makes it more opinionated but also more complete out of the box. Good for teams that want an integrated solution without assembling components.
Cloud-managed. SageMaker Feature Store (AWS), Vertex AI Feature Store (GCP), and Azure ML Feature Store provide managed online and offline stores integrated with each cloud's ML ecosystem. These reduce operational burden but create vendor lock-in. Best for organizations already deep in one cloud's ML stack.
Commercial — Tecton. Production-grade feature store with a strong real-time focus. Tecton handles both batch and streaming feature computation, and is designed for teams running models that need sub-100ms feature serving. The trade-off is cost and complexity compared to lighter options like Feast.
Feature Governance
Every feature needs metadata: definition (what it measures), owner (who maintains it), source data (where it comes from), computation logic (how it is calculated), freshness SLA (how often it updates), quality checks (what validation runs), and downstream consumers (which models use it).
Without governance, feature stores become another data swamp — thousands of features with no documentation, unclear ownership, and no way to assess the impact of changes. A team changes the definition of "active_customer" in one feature pipeline and breaks three models that depended on the old definition. Nobody knows until model performance degrades weeks later.
Feature registries are, in effect, specialized data catalogs for ML features. They apply the same principles of data governance — documentation, ownership, lineage, quality monitoring — to the specific domain of model inputs. Organizations running both a feature store and a data catalog benefit from connecting them: the feature registry documents the feature, and the data catalog documents the source data the feature is built from.
How Dawiso Supports Feature Stores
Feature stores manage ML-specific metadata; Dawiso's data catalog manages the broader data estate. The connection point: features are built from source datasets documented in Dawiso.
Data lineage traces from a feature back through transformations to the raw source table — and Dawiso documents what that source table contains, who owns it, and what quality rules apply. When a feature starts producing unexpected values, lineage pinpoints whether the issue is in the feature pipeline or in the upstream source data.
The business glossary ensures that terms like "active_customer" and "revenue" have one canonical definition across the organization. Feature store registries reference these definitions, so a feature labeled "monthly_active_users" computes it the same way the business glossary defines it — not some team's local interpretation.
Through the Model Context Protocol (MCP), feature pipelines can verify source dataset freshness and schema before computing features. If the orders table was not updated in the last 24 hours, the pipeline halts with a clear error rather than computing stale features that silently degrade model accuracy.
Conclusion
A feature store is not a nice-to-have once you are running more than a few models. It is the infrastructure that prevents feature duplication, eliminates training-serving skew, and makes features discoverable across teams. The technology is mature — open-source and managed options cover most use cases. The harder part is governance: ensuring every feature is documented, owned, and traceable back to its source.
