Feature store
Last reviewed
Sources
No citations yet
Review status
Needs citations
Revision
v2 · 4,171 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
Sources
No citations yet
Review status
Needs citations
Revision
v2 · 4,171 words
Add missing citations, update stale details, or suggest a clearer explanation.
A feature store is a centralised data system that stores, serves, discovers, shares, monitors and reuses machine-learning features, separating feature computation from model training and inference so the same feature values are reliably reused across models and across the training-versus-serving boundary. The term entered public usage in September 2017, when Uber published its Michelangelo blog post and described the feature store as the platform's most important component for scaling machine learning across the company; Uber reported "approximately 10,000 features in Feature Store" in production at that time.1 Its core job is to solve three recurring failures of production machine learning: train/serve skew (the same feature behaving differently in training and serving), feature reuse (many teams recomputing the same signal), and point-in-time correctness (joining each training label to feature values as they existed at that label's timestamp, without leaking the future).123
A feature, in this context, is any signal derived from raw data that a model consumes as input. Examples include a user's seven-day rolling order count, the average tip percentage in a city last hour, or the embedding of a product description. A feature store does not invent these signals. It standardises how they are defined, computed, materialised, served and audited so that the feature engineering pipeline becomes a piece of shared infrastructure rather than a per-model script. Feature stores are a foundational layer of the MLOps stack, sitting between raw data platforms and the machine learning models that consume features.
Most large machine-learning teams arrived at the same set of complaints between 2016 and 2020. Features computed in batch for training behaved differently in production. Two teams shipped slightly different versions of the same "days since last purchase" feature. Backfilling a year of historical features for a new label took weeks. Nobody could tell whether a feature had drifted because nobody could tell who owned it. A feature store is the consolidation of those complaints into a single piece of infrastructure.
Uber's Michelangelo team framed the reuse problem directly: "We found that many modeling problems at Uber use identical or similar features, and there is substantial value in enabling teams to share features between their own projects and for teams in different organizations to share features with each other."1 The same post described preventing skew as a configuration guarantee: "the same expressions are applied at training time and at prediction time to help guarantee that the same final set of features is generated and sent to the model in both cases."1
The table below lists the recurring industry pain points that feature stores were built to solve.
| Problem | What goes wrong without a feature store | How a feature store helps |
|---|---|---|
| Training-serving skew | Features computed in a batch SQL job for training behave differently when reimplemented in a Java or Python service for online inference, which causes silent prediction failures. | The same feature definition produces both the offline training set and the online lookup, so the values seen by the model are identical in both environments.12 |
| Feature reuse | The same feature is recomputed by N teams for N models, wasting engineering time and producing slightly inconsistent values. | A registry lets practitioners search for an existing feature and consume it as is, rather than rebuilding it from raw tables.14 |
| Backfilling and point-in-time correctness | Historical training labels need feature values as they existed at the label timestamp, not the latest values, otherwise the training set leaks future information. | The offline store supports time-travel joins (often called AS OF joins) so that each label row is paired with feature values that were valid at that label's time.35 |
| Discovery | Data scientists rebuild features that already exist somewhere because nobody knows the inventory. | A feature catalog lists definitions, owners, freshness and downstream consumers.26 |
| Monitoring and drift detection | Distribution drift in input features is hard to spot when each model logs features in its own way. | A central store can attach drift, freshness and quality metrics to every feature group.78 |
| Governance and compliance | Auditors cannot tell what data trained which model, and personally identifiable inputs are scattered. | Lineage from raw source through feature view to model registry gives a single audit trail.2 |
The idea of pre-computing reusable model inputs and serving them from a fast store predates the term "feature store." Internal versions existed at search and ads companies long before 2017. The label, and the broader notion of a shared platform component for features, came out of Uber.
2017: Uber Michelangelo. On 5 September 2017, Jeremy Hermann (engineering manager) and Mike Del Balso (product manager) published "Meet Michelangelo: Uber's Machine Learning Platform." The post described a centralised feature store the team summarised as a system "in which teams around Uber can create and manage canonical features to be used by their teams and shared with others," holding roughly 10,000 features in production at the time, supporting both daily batch features in HDFS and near-real-time features written to Cassandra by Samza streaming jobs. The team explicitly named feature reuse and consistent training-versus-serving values as the two central goals.1
2017 to 2018: Other tech companies built their own. Airbnb began work on a feature engineering framework originally called Zipline in 2017, which was later renamed Chronon and open-sourced in April 2024.5 Twitter, LinkedIn, Spotify and Netflix built internal feature platforms in roughly the same window. LinkedIn later open-sourced Feathr; DoorDash described an internal store called Fabricator; Stripe became an early Chronon adopter and co-maintainer.35
2018: Hopsworks. Logical Clocks released the first version of the Hopsworks Feature Store at the end of 2018, with an API based on FeatureGroup data frames.9 Hopsworks remains one of the few feature stores explicitly designed around an open-format lakehouse, today using Apache Hudi and Iceberg.10
2019: Feast goes public. Gojek, the Indonesian ride-hailing and payments company, partnered with Google Cloud to build Feast and open-sourced it in January 2019. Gojek had more than ten teams independently shipping models for pricing, matching, fraud and recommendations, and they kept rebuilding the same data plumbing. Feast was the consolidation of that work and became the first widely adopted open-source feature store.1112 It is licensed under Apache 2.0 and is now hosted by the Linux Foundation AI & Data project.4
2020: Tecton launches commercially. Mike Del Balso (CEO), Jeremy Hermann (VP of Engineering) and Kevin Stumpf (CTO), the team behind Uber's Michelangelo feature store, founded Tecton in 2019 and emerged from stealth on 28 April 2020 with $25 million from Andreessen Horowitz and Sequoia.13 Tecton released its cloud-native enterprise feature store on 7 December 2020 alongside a $35 million Series B.14 In July 2022 it raised a $100 million Series C led by Kleiner Perkins, with strategic participation from Databricks and Snowflake Ventures, bringing total funding to $160 million at a roughly $900 million valuation.1516 In August 2025 Databricks announced it was acquiring Tecton, calling it "the leading real-time enterprise feature store," to power real-time data for AI agents.17
December 2020: AWS SageMaker Feature Store. Amazon announced SageMaker Feature Store at re:Invent on 1 December 2020, with general availability on 8 December 2020. AWS describes it as "a fully managed repository that helps maintain consistency between features used at the time of inference and model training."6 It is a managed dual-store service: an online store for low-latency lookups and an offline store backed by S3 for training and exploration with Athena, Spark or EMR.618
May 2021: Databricks Feature Store. Databricks announced its feature store on 27 May 2021, positioning it as "the first feature store co-designed with an MLOps framework and a data and analytics platform," integrated with Delta Lake and MLflow.2 Lineage and discovery flow through the same metadata that already tracks tables and notebooks; deployed MLflow models can call the store directly at inference time. The feature store has since migrated under Unity Catalog as Databricks Feature Engineering, with the legacy databricks-feature-store package deprecated in favour of databricks-feature-engineering 0.2 and later.219
May 2021: Vertex AI Feature Store. Google launched Vertex AI in May 2021, with a feature store among its core components.3 In October 2023 Google announced a redesigned BigQuery-powered Vertex AI Feature Store that treats BigQuery itself as the offline store and adds a managed online serving layer with low-latency lookups, plus native vector embedding support.20
2023 to 2024: Azure ML managed feature store. Microsoft announced the Azure Machine Learning managed feature store at Build in May 2023; the SDK reached version 1.0 in November 2023, marking general availability. Subsequent 2024 releases added custom feature sources, sovereign cloud regions and improved offline backfill materialisation.21
April 2024: Chronon (formerly Zipline) open source. Airbnb open-sourced Chronon, its production feature platform, in April 2024 alongside Stripe as an early adopter and co-maintainer. Chronon focuses on feature definitions that target both batch warehouses and streaming pipelines from a single declaration.5
A standard feature store has five layers. They can be drawn as a diagram, but in prose the picture is:
get_historical_features) and from production services (get_online_features).46Materialisation is the glue. Features computed in the offline pipeline get pushed ("materialised") into the online store on a schedule so that production lookups return the same values that training saw.21
The online/offline split is the defining structural feature of a feature store and the source of its train/serve guarantee. The offline store is optimised for high-throughput historical reads (whole columns, millions of rows) to build training sets, while the online store is optimised for single-key, low-latency reads at inference. The two are kept in sync by materialisation so the model sees the same value in both worlds.
| Property | Offline store | Online store |
|---|---|---|
| Purpose | Training data generation, batch scoring, exploration | Real-time feature lookup at inference |
| Read pattern | Large columnar scans, point-in-time joins | Single-entity key lookups |
| Typical backends | S3 + Parquet, Delta, BigQuery, Snowflake, Hive | Redis, DynamoDB, Cassandra, Bigtable, RonDB, Postgres |
| Latency target | Minutes to hours acceptable | Single-digit to low double-digit milliseconds |
| Data retained | Full history (for point-in-time correctness) | Latest value per entity (subject to TTL) |
| Source for | The model's training set | The model's live prediction request |
The vocabulary is mostly stable across vendors, with small differences in spelling.
| Term | Meaning |
|---|---|
| Entity | The unit of analysis a feature is keyed by, such as user_id, restaurant_id, session_id or a composite key. Entities are how features are joined to training labels and to inference requests.46 |
| Feature view (Feast, Tecton) / feature group (Hopsworks, Databricks) | A logical grouping of features that share an entity, a source and a refresh schedule. The unit of definition that practitioners write and version in Git.410 |
| Feature service | A bundle of feature views consumed by a particular model. Lets the model declare its full input contract in one place.4 |
| Point-in-time correctness | The guarantee that, for every training row, feature values are taken as they were at the row's label timestamp. Implemented via AS OF joins or time-travel joins. Without this, training sets leak future information into the past and inflate offline metrics.35 |
| Materialisation | The process of computing features from the offline pipeline and writing them into the online store, on a schedule or on demand.21 |
| Freshness and time-to-live (TTL) | How recently a feature was updated and how long it remains valid for online lookup. Strict freshness budgets matter for fraud and ads; relaxed TTLs are fine for slow-moving demographics.58 |
| On-demand transformation (also called request-time feature) | A feature computed at inference using inputs that only exist at request time, such as the user's query string or current geolocation. Tecton, Feast and Chronon all support these.45 |
| Backfill | Computing historical feature values for a new feature so it can be used to train a model on past labels. This is the operation that makes point-in-time correctness expensive.3 |
The table below compares the systems most teams actually evaluate.
| System | Open source / commercial | Deployment model | Online store options | Streaming support | First released | Notable users |
|---|---|---|---|---|---|---|
| Feast | Open source (Apache 2.0) | Self-hosted; runs on any cloud, Kubernetes or local | Redis, DynamoDB, Bigtable, Cassandra, Postgres, Snowflake, SQLite, Dragonfly, ScyllaDB, Milvus, Qdrant and others | Push API for Kafka and Kinesis sources | January 2019 (Gojek and Google) | Robinhood, NVIDIA, Discord, Cloudflare, Walmart411 |
| Tecton | Commercial (now part of Databricks) | Managed SaaS on AWS, GCP, Azure | Tecton-managed, with options for DynamoDB or Redis on the customer side | Native Spark Structured Streaming and Kafka pipelines, sub-100 ms freshness | Launched April 2020 | Atlassian, Plaid, Cash App, HelloFresh, Coinbase1322 |
| Hopsworks | Open core (AGPL with commercial editions) | Self-hosted, Kubernetes, or Hopsworks managed | RonDB (default), plus Redis and others | Native Flink and Spark Structured Streaming | Late 2018 | Logical Clocks customers in finance, telco and gaming910 |
| Databricks Feature Engineering / Feature Store | Commercial (part of Databricks) | Managed inside Databricks workspaces | Cosmos DB, DynamoDB, MySQL, plus Databricks Online Tables | Streaming via Spark Structured Streaming on the lakehouse | May 2021 | Databricks customers including ABN AMRO, Block, Comcast, Walgreens219 |
| AWS SageMaker Feature Store | Commercial (part of AWS) | Managed in AWS | Online store backed by managed key-value layer; offline in S3 | Ingestion via Kinesis, Kafka MSK and PutRecord API | 8 December 2020 | Customers including 3M, JPMorgan Chase, Vanguard618 |
| Vertex AI Feature Store | Commercial (part of Google Cloud) | Managed in GCP | Optimised online serving and Bigtable serving; BigQuery as the offline source | Streaming through Dataflow into BigQuery sources | May 2021; BigQuery-powered redesign October 2023 | Wayfair, Cash App, Spotify, Shopify20 |
| Azure ML managed feature store | Commercial (part of Azure ML) | Managed in Azure ML workspaces | Online store via Azure Cache for Redis | Streaming sources via Spark Structured Streaming on Azure | Preview May 2023; SDK 1.0 in November 2023 | Microsoft enterprise customers21 |
| Featureform | Open source (MPL 2.0); now part of Redis | Virtual store layered on existing data infrastructure | Whatever the customer brings: Redis, DynamoDB, Postgres, vector DBs | Yes, on the underlying engine | 2021 | Open-source community; acquired by Redis23 |
| Chronon (Airbnb) | Open source (Apache 2.0) | Self-hosted on Spark and Flink, with a serving service | Customer-provided key-value store | First-class batch and streaming with consistency-measurement pipelines | Open-sourced April 2024 (internal since 2017 as Zipline) | Airbnb, Stripe5 |
Feature stores are one of those technologies where the second-order failures show up only after a year of use. The recurring traps:
The shape of feature platforms is still moving. Five trends are visible across vendor blogs, conference talks and the MLOps Community feature-store summits.
Real-time features become standard. Fraud, ads bidding, recommendations and dynamic pricing all need features that reflect what happened seconds ago. Tecton, Chronon and Hopsworks all advertise sub-second feature freshness as a first-class capability rather than an advanced add-on.225
On-demand features for LLM and agent applications. When a feature depends on the user's prompt, their current cart contents, or the output of an upstream model, it cannot be precomputed. Feast added on-demand transformations as a beta in 2024; Tecton positions on-demand pipelines as a core part of its "AI feature platform."422
Tighter integration with the lakehouse. Databricks Feature Engineering lives inside Unity Catalog and reuses Delta Lake for storage and lineage. Vertex AI Feature Store stores offline features directly in BigQuery rather than copying them out. Hopsworks builds its offline store on Hudi and Iceberg.192010 The boundary between "the data platform" and "the feature store" is thinning.
Feature stores and vector databases converge. A feature store and a vector database solve adjacent problems: both serve precomputed model inputs by entity key at low latency, but a vector database is specialised for nearest-neighbour search over embeddings used in retrieval-augmented generation, while a feature store serves structured features for prediction. The two are merging from both directions. Feast added Milvus and Qdrant as supported online stores; Vertex AI Feature Store added native vector embedding storage and similarity search; Featureform was "built from the ground up with embeddings in mind" and is now part of Redis. As retrieval-augmented generation systems mix structured features with embeddings, the two categories of infrastructure increasingly overlap.42023
"Feature platform" terminology. Tecton, Chip Huyen and the Chronon team prefer "feature platform" over "feature store" because the storage layer is only one of four components (the others being feature definitions, computation engines and serving APIs). The term "feature store" is sticky enough that both labels are now used interchangeably in practice.322
Not every team needs a feature store, and the category has its skeptics. Three lines of critique recur:
Three publicly documented designs are useful starting points for teams building or evaluating their own platform.
The principal feature stores in production today are:
Feature stores are part of the broader MLOps tool stack and overlap with experiment tracking (MLflow, Weights & Biases), model registries, online serving infrastructure and observability platforms. Many teams adopt a feature store at the same time they consolidate on a model registry and a serving framework, treating all three as components of a single ML platform.
Hermann, J. and Del Balso, M. (5 September 2017). "Meet Michelangelo: Uber's Machine Learning Platform." Uber Engineering Blog. https://www.uber.com/blog/michelangelo-machine-learning-platform/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
Lewandowski, K. and team (27 May 2021). "Databricks Announces the First Feature Store Integrated with Delta Lake and MLflow." Databricks Blog. https://www.databricks.com/blog/2021/05/27/databricks-announces-the-first-feature-store-integrated-with-delta-lake-and-mlflow.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10
Huyen, C. (2022). "Designing Machine Learning Systems," O'Reilly. Also Huyen, C. (8 January 2023). "Self-serve feature platforms: architectures and APIs." https://huyenchip.com/2023/01/08/self-serve-feature-platforms.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Feast project documentation and source. https://feast.dev and https://github.com/feast-dev/feast (Apache 2.0; hosted by the LF AI & Data Foundation). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14
Zanoyan, V. (April 2024). "Chronon, Airbnb's ML Feature Platform, Is Now Open Source." Airbnb Tech Blog. https://medium.com/airbnb-engineering/chronon-airbnbs-ml-feature-platform-is-now-open-source-d9c4dba859e8 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
AWS (8 December 2020). "Introducing Amazon SageMaker Feature Store - a fully managed repository to store, discover, share and serve machine learning features." https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-amazon-sagemaker-feature-store/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
Aerospike (2024). "Feature Store 101: Build, Serve, and Scale ML Features." https://aerospike.com/blog/feature-store/ ↩ ↩2
Yan, E. "Feature Stores: A Hierarchy of Needs." Applying ML resources. https://applyingml.com/resources/feature-stores/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
Logical Clocks blog. "Hopsworks Feature Store API 2.0" and "Feature Stores in Production." https://www.logicalclocks.com/blog/hopsworks-feature-store-api-2-0 ↩ ↩2
Hopsworks documentation and product page. https://www.hopsworks.ai/ ↩ ↩2 ↩3 ↩4 ↩5
Yong, W. and Diaz, V. (2019). "Introducing Feast: an open source feature store for machine learning." Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/introducing-feast-an-open-source-feature-store-for-machine-learning ↩ ↩2
Gojek Engineering. "Feast: Bridging ML Models and Data." https://www.gojek.io/blog/feast-bridging-ml-models-and-data ↩
GlobeNewswire (28 April 2020). "Founded by Creators of Uber Michelangelo, Tecton.ai Launches to Make World-Class Machine Learning Accessible to Every Company With $25 Million From Andreessen Horowitz and Sequoia." https://www.globenewswire.com/news-release/2020/04/28/2023454/0/en/Founded-by-Creators-of-Uber-Michelangelo-Tecton-ai-Launches.html ↩ ↩2
GlobeNewswire (7 December 2020). "Tecton Releases Cloud-Native Enterprise Feature Store for Machine Learning, Raises $35 Million Series B Co-Led by Andreessen Horowitz and Sequoia." https://www.globenewswire.com/news-release/2020/12/07/2140792/0/en/Tecton-Releases-Cloud-Native-Enterprise-Feature-Store-for-Machine-Learning.html ↩
Tecton blog (12 July 2022). "Tecton Raises $100M in Series C Funding." https://www.tecton.ai/blog/tecton-raises-100m-in-series-c-funding/ ↩
Wiggers, K. (12 July 2022). "Tecton raises $100M, proving that the MLOps market is still hot." TechCrunch. https://techcrunch.com/2022/07/12/tecton-raises-100m-proving-that-the-mlops-market-is-still-hot/ ↩
Databricks blog (August 2025). "Tecton is Joining Databricks to Power Real-Time Data for Personalized AI Agents." https://www.databricks.com/blog/tecton-joining-databricks-power-real-time-data-personalized-ai-agents ↩ ↩2
AWS Machine Learning Blog. "Understanding the key capabilities of Amazon SageMaker Feature Store." https://aws.amazon.com/blogs/machine-learning/understanding-the-key-capabilities-of-amazon-sagemaker-feature-store/ ↩ ↩2
"Databricks feature engineering and legacy Workspace Feature Store release notes." Databricks documentation. https://docs.databricks.com/aws/en/release-notes/feature-store/databricks-feature-store ↩ ↩2 ↩3 ↩4
Cucereavii, M. and Patil, A. (10 October 2023). "New Vertex AI Feature Store: BigQuery-Powered, GenAI-Ready." Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/new-vertex-ai-feature-store-bigquery-powered-genai-ready ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Microsoft (May 2023). "Announcing managed feature store in Azure Machine Learning." Microsoft Tech Community. https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/announcing-managed-feature-store-in-azure-machine-learning/3823043 ↩ ↩2 ↩3 ↩4 ↩5
Tecton product documentation (2025). https://docs.tecton.ai/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Featureform documentation and GitHub. https://www.featureform.com and https://github.com/featureform/featureform (MPL 2.0; acquired by Redis). ↩ ↩2 ↩3 ↩4