Skip to main content
Bureau of AI
Category: Model Lifecycle & MLOps

Feature Store

Also known as: managed feature store, ML feature store
Simply put

A feature store is a centralized platform where the prepared data inputs used by machine learning models—known as features—are defined, stored, and made available for reuse. It provides a single, shared place from which multiple teams and projects can access the same pre-computed features, rather than each rebuilding them independently. This aims to reduce repetitive data work and support consistency across the models that consume those features.

Formal definition

A feature store is a centralized repository and serving layer for defining, storing, sharing, and managing machine learning features—typically pre-computed, reusable data attributes—intended to serve as a single source of truth for both model training and inference. As commonly implemented (for example, as a dedicated workspace or managed service integrable with compute environments such as Spark), it standardizes feature definitions, supports feature reuse across projects, and provides mechanisms to create, store, and serve features for consuming models. Note that specific capabilities, architecture, and terminology vary across vendor implementations; the evidence here describes general and platform-specific characterizations rather than a single authoritative standard. This entry addresses feature stores as ML infrastructure and does not itself define governance or model risk controls, though the consistency and lineage such systems can provide may support those functions.

Why it matters

Feature stores address a recurring source of inconsistency in machine learning: the data inputs, or features, that models rely on. When individual teams each build their own version of a feature, the same conceptual input can be computed differently across projects, and the features used to train a model may diverge from those served at inference time. By providing a centralized repository intended to act as a single source of truth, a feature store aims to reduce this fragmentation and support consistency across the models that consume shared features.

From a governance and model risk management perspective, this consistency and the lineage such systems can provide may be useful supporting inputs rather than controls in themselves. Model risk management typically depends on being able to identify, reproduce, and monitor the data a model consumes; a centralized feature definition can make it easier to trace which features feed which models and to reason about how a change to a feature might propagate. It is important not to overstate this: a feature store is machine learning infrastructure, and it does not by itself perform validation, establish accountability, or manage model risk. The consistency it can offer may reduce certain sources of error, but it does not eliminate risk.

Because capabilities, architecture, and terminology vary substantially across vendor implementations, organizations should not assume that all feature stores provide the same governance-relevant features, such as lineage tracking or access controls. The evidence here describes general and platform-specific characterizations rather than a single authoritative standard, and any reliance on a feature store to support risk or governance functions should be assessed against the specific implementation in use.

Who it's relevant to

Data scientists and ML engineers
These practitioners create, store, and reuse features across models. A feature store aims to reduce repetitive data engineering work and to keep the features used in training consistent with those served at inference, though the specific capabilities available depend on the platform implementation.
Model risk managers and validators
The consistency and lineage a feature store can provide may support the traceability and reproducibility that model risk functions typically rely on. This is a supporting input, not a risk control in itself; a feature store does not perform validation or manage model risk, and its usefulness for these purposes depends on whether the specific implementation offers lineage and access capabilities.
AI governance and oversight teams
Governance teams concerned with accountability and oversight of AI systems may find that centralized feature definitions help clarify which data inputs feed which models. However, a feature store is machine learning infrastructure rather than a governance framework, and it does not by itself establish policies, accountability, or controls.
Auditors and compliance professionals
For those tracing how models consume data, a centralized feature repository may make it easier to identify shared inputs and their reuse across projects. Because features, architecture, and terminology vary across vendor implementations, auditors should verify what lineage, access, and documentation capabilities a given feature store actually provides rather than assuming a common standard.

Inside Feature Store

Feature Definitions and Transformations
The logic that converts raw source data into engineered features, including aggregations, encodings, and derived variables. In many implementations this logic is version-controlled so that the same transformation can be reproduced across training and serving contexts.
Online Store
A low-latency serving layer that provides current feature values for real-time inference. It is typically optimized for fast lookups rather than large-scale historical retrieval.
Offline Store
A repository of historical feature values used for model training and batch scoring. It commonly supports point-in-time retrieval so that training data reflects the feature values available as of a given moment.
Feature Registry / Metadata Catalog
A catalog describing available features, their owners, data lineage, definitions, and dependencies. This metadata supports discoverability and, where maintained, can contribute to model documentation and audit trails.
Serving and Retrieval APIs
Interfaces through which training pipelines and production models request feature values, intended to provide a consistent access path across the online and offline stores.
Consistency Mechanisms
Controls intended to reduce training-serving skew by aligning the feature values used during model development with those used at inference time. The degree of consistency achieved depends on implementation.

Common questions

Answers to the questions practitioners most commonly ask about Feature Store.

Is a feature store the same as a model registry or a general-purpose data warehouse?
No. A feature store is typically a system for defining, storing, serving, and reusing engineered features (model inputs) across training and inference, whereas a model registry manages versioned models and their metadata, and a data warehouse stores raw or transformed data more broadly. These components often coexist in a machine learning platform, but conflating them obscures distinct responsibilities. Professionals should be precise about which system governs feature definitions versus which governs model artifacts, as the associated controls and lineage requirements differ.
Does adopting a feature store by itself ensure consistency between training and production, or reduce model risk?
Not on its own. A feature store is commonly used to help address training-serving skew by providing a shared definition and serving path for features, but it reduces rather than eliminates the risk of inconsistency, and its effectiveness depends on how it is configured, governed, and monitored. It is a supporting control within broader model risk management practices, not a guarantee. Treating the tool as a substitute for validation, monitoring, or governance is a frequent error.
What distinguishes an online store from an offline store within a feature store, and when is each used?
Feature stores commonly separate an offline store, optimized for batch access to historical feature values used in training and backtesting, from an online store, optimized for low-latency retrieval of current feature values used at inference time. The two are typically expected to serve consistent definitions of the same feature so that a feature computed for training matches what is served in production. Implementation teams should confirm how consistency between the two paths is maintained and monitored rather than assuming it is automatic.
How does a feature store support lineage and reproducibility for models under review?
Feature stores are often used to record feature definitions, transformation logic, and versioning, which can support the ability to reconstruct the inputs a model saw at a given time. This lineage can assist validation and audit activities by clarifying what data fed a model. However, the completeness of lineage depends on what the store actually captures; teams should verify whether upstream data sources, transformation code, and point-in-time correctness are fully traceable rather than presuming full reproducibility.
What is point-in-time correctness and why does it matter when generating training data from a feature store?
Point-in-time correctness generally refers to constructing training datasets so that each feature value reflects only information that would have been available at the relevant historical moment, avoiding the use of future information. This is commonly important to prevent data leakage that can inflate apparent model performance. When implementing a feature store, teams should confirm how the offline store handles point-in-time joins, because incorrect handling can introduce leakage that undermines validation results.
What governance and access controls are typically relevant when operating a shared feature store?
Because feature stores are frequently intended to enable reuse across teams and models, governance considerations commonly include access controls over who can create, modify, or consume features, documentation of feature ownership and definitions, and monitoring of feature quality and freshness. These controls support accountability and can reduce the risk of unmanaged reuse, but the specific requirements depend on organizational policy and applicable oversight expectations. The appropriate control set should be defined in the context of the organization's overall AI governance and model risk management framework rather than assumed from the tool alone.

Common misconceptions

A feature store guarantees the elimination of training-serving skew.
A feature store is a measure that can reduce skew by centralizing and reusing feature logic, but it does not eliminate the risk. Skew can still arise from data pipeline differences, timing effects, upstream data changes, or inconsistent transformation logic between environments.
Adopting a feature store satisfies model risk management or AI governance obligations.
A feature store is a data infrastructure component. It may support governance and model risk management activities—for example by providing lineage, versioning, and documentation inputs—but it does not by itself perform validation, monitoring, or oversight. Governance structures and model risk controls remain separate responsibilities that operate on top of such tooling.
The metadata and lineage captured by a feature store constitute complete model documentation.
Feature-level lineage typically covers only the feature engineering portion of a model's lifecycle. Comprehensive model documentation, as commonly expected in model risk contexts, also addresses model design, assumptions, validation, limitations, and monitoring, which fall outside the scope of a feature store.

Best practices

Version-control feature definitions and transformation logic so that training and serving use reproducible, identifiable versions, and so that historical model behavior can be reconstructed.
Use point-in-time retrieval from the offline store when constructing training datasets to reduce the risk of target leakage from features that would not have been available at the relevant time.
Maintain feature-level ownership, lineage, and metadata in the registry to support discoverability and to provide documentation inputs that governance and model risk functions may draw upon.
Monitor for training-serving skew rather than assuming the feature store prevents it, comparing feature distributions and values between the offline and online paths over time.
Treat the feature store as one input to model documentation and validation rather than a substitute for them, and coordinate its use with your organization's governance and model risk processes.
Establish access, change-management, and data-quality controls around shared features, since features reused across multiple models can propagate errors or unintended behavior more widely.