A feature store is a data system built specifically for machine learning, whose job is to define, store, and serve the features that models consume. A feature is a computed input to a model, such as a customer’s average order value over the last thirty days or the number of trips a driver completed today. In a mature ML organization the same feature is often used by many models and many teams, and a feature store exists to compute each feature once, store it, and serve it consistently wherever it is needed.
The concept was crystallized inside Uber’s Michelangelo platform. Uber’s own engineering description explains that once features are placed in its feature store they become “very easy to consume, both online and offline, by referencing a feature’s simple canonical name.” Michelangelo’s store let data scientists reuse curated, shareable features rather than re-deriving them, which reduced duplicated work and improved consistency across projects.
The central technical problem a feature store solves is training-serving skew. A model is trained on historical feature values and then asked to make predictions on freshly computed feature values in production. If the two code paths compute a feature even slightly differently, the model sees inputs at serving time that do not match what it learned from, and accuracy quietly degrades. A feature store addresses this by giving both paths a single definition and, ideally, shared computation.
To do this, feature stores typically separate two concerns. An offline store holds large volumes of historical feature values for model training and batch scoring, and must support point-in-time correct retrieval so that a training example only ever sees feature values that were known at the moment it occurred, avoiding data leakage from the future. An online store holds the latest feature values in a low-latency database so that a live prediction request can fetch them in milliseconds. The open-source project Feast, which describes itself as a feature store that lets teams “define, manage, validate, and serve features for production AI/ML,” made this offline/online split a widely understood pattern.
The feature store is one of the defining pieces of MLOps infrastructure. It treats features as durable, versioned, reusable assets with clear ownership rather than as throwaway code buried inside a single training script, and in doing so it brings the same discipline to a model’s inputs that version control brought to its source.