# Feature store

> Source: https://aiwiki.ai/wiki/feature_store
> Updated: 2026-06-23
> Categories: AI Infrastructure, MLOps
> From AI Wiki (https://aiwiki.ai), a free encyclopedia of artificial intelligence. Quote with attribution.

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.[^uber2017] 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).[^uber2017][^databricks2021][^huyen2023]

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](/wiki/feature_engineering) pipeline becomes a piece of shared infrastructure rather than a per-model script. Feature stores are a foundational layer of the [MLOps](/wiki/mlops) stack, sitting between raw data platforms and the [machine learning](/wiki/machine_learning) models that consume features.

## Why do feature stores exist?

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."[^uber2017] 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."[^uber2017]

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](/wiki/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](/wiki/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.[^uber2017][^databricks2021] |
| 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.[^uber2017][^feast] |
| 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.[^huyen2023][^chronon2024] |
| Discovery | Data scientists rebuild features that already exist somewhere because nobody knows the inventory. | A feature catalog lists definitions, owners, freshness and downstream consumers.[^databricks2021][^aws2020] |
| 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.[^aerospike2024][^applyingml] |
| 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.[^databricks2021] |

## History: when was the feature store invented?

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.[^uber2017]

**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.[^chronon2024] 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.[^huyen2023][^chronon2024]

**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.[^logicalclocks2020] Hopsworks remains one of the few feature stores explicitly designed around an open-format lakehouse, today using Apache Hudi and Iceberg.[^hopsworks]

**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.[^feastgcp2019][^gojek] It is licensed under Apache 2.0 and is now hosted by the Linux Foundation AI & Data project.[^feast]

**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.[^tectonlaunch] Tecton released its cloud-native enterprise feature store on 7 December 2020 alongside a $35 million Series B.[^tectonseriesb] 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.[^tectonseriesc][^tcrunch2022] 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.[^databrickstecton]

**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."[^aws2020] 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.[^aws2020][^awsblog2020]

**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.[^databricks2021] 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.[^databricks2021][^databricksrelease]

**May 2021: Vertex AI Feature Store.** Google launched Vertex AI in May 2021, with a feature store among its core components.[^huyen2023] 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.[^vertex2023]

**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.[^azure2023]

**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.[^chronon2024]

## How does a feature store work?

A standard feature store has five layers. They can be drawn as a diagram, but in prose the picture is:

1. **Data sources** sit at the top. These are the raw substrate: data warehouse tables (Snowflake, BigQuery, Redshift, Databricks Delta), object storage (S3 + Parquet), event streams (Kafka, Kinesis, Pulsar), and operational databases (Postgres, MySQL, DynamoDB). Some real-time features also depend on request-time inputs that arrive only at inference, such as a search query string.[^feast][^huyen2023]
2. **Feature pipelines** transform raw data into feature values. Batch pipelines run on Spark, dbt, Snowflake SQL or BigQuery. Streaming pipelines run on Flink, Kafka Streams or Spark Structured Streaming. On-demand transformations execute at request time using Python, SQL or domain-specific languages provided by the feature store SDK.[^feast][^chronon2024]
3. **Offline store** persists historical feature values, usually in a columnar format on a data lake or warehouse (Parquet on S3, Delta on Databricks, BigQuery, Snowflake). It is the source of truth for training data and supports point-in-time joins.[^databricks2021][^aerospike2024]
4. **Online store** holds the latest feature values keyed by entity for low-latency lookup at inference time. Common backends are Redis, DynamoDB, Cassandra, Bigtable and Postgres. Tecton advertises sub-10 millisecond serving latency.[^tecton2025]
5. **Feature registry and serving SDK** sit alongside the two stores. The registry holds metadata: feature definitions, owners, schemas, freshness, lineage. The SDK is what data scientists actually call from notebooks (`get_historical_features`) and from production services (`get_online_features`).[^feast][^aws2020]

Materialisation 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.[^azure2023]

## What is the difference between the online store and the offline store?

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 |

## Key concepts

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.[^feast][^aws2020] |
| 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.[^feast][^hopsworks] |
| Feature service | A bundle of feature views consumed by a particular model. Lets the model declare its full input contract in one place.[^feast] |
| 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.[^huyen2023][^chronon2024] |
| Materialisation | The process of computing features from the offline pipeline and writing them into the online store, on a schedule or on demand.[^azure2023] |
| 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.[^chronon2024][^applyingml] |
| 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.[^feast][^chronon2024] |
| 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.[^huyen2023] |

## What are the major feature store systems?

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](https://feast.dev) | 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, Walmart[^feast][^feastgcp2019] |
| 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, Coinbase[^tectonlaunch][^tecton2025] |
| 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 gaming[^logicalclocks2020][^hopsworks] |
| 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, Walgreens[^databricks2021][^databricksrelease] |
| 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, Vanguard[^aws2020][^awsblog2020] |
| 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, Shopify[^vertex2023] |
| 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 customers[^azure2023] |
| 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 Redis[^featureform] |
| 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, Stripe[^chronon2024] |

## Common pitfalls

Feature stores are one of those technologies where the second-order failures show up only after a year of use. The recurring traps:

- **Treating it as a data warehouse export.** A feature store is not just "the offline table with extra metadata." Without the online serving path and point-in-time semantics, you have a catalog, not a feature store.[^applyingml]
- **Underestimating point-in-time correctness.** Implementing AS OF joins efficiently across hundreds of features and millions of rows is harder than it looks. Naive implementations leak label information or take hours to materialise a single training set.[^huyen2023][^chronon2024]
- **Skipping monitoring and lineage.** Without freshness alerts and drift dashboards, the store becomes another silent dependency. Production failures show up as model accuracy regressions weeks later.[^applyingml]
- **Overengineering.** A team with one or two models and a daily batch inference job often does not need a feature store. The dual-store cost and operational overhead can swamp the gains. Eugene Yan and Chip Huyen both warn against adopting a feature store before the team actually has the pain it solves.[^applyingml][^huyen2023]
- **Schema and ownership churn.** Once dozens of teams depend on a feature view, breaking changes are expensive. Strict versioning and clear owners are needed from day one.[^databricks2021]
- **Cost.** Maintaining an offline store, an online store, continuous materialisation jobs and streaming pipelines for low-latency features can add up quickly. Vertex AI's BigQuery-centric redesign and Featureform's virtual layer were both partly responses to this complaint.[^vertex2023][^featureform]

## How do feature stores relate to RAG and vector databases?

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.[^tecton2025][^chronon2024]

**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."[^feast][^tecton2025]

**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.[^databricksrelease][^vertex2023][^hopsworks] 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](/wiki/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](/wiki/retrieval-augmented_generation) systems mix structured features with embeddings, the two categories of infrastructure increasingly overlap.[^feast][^vertex2023][^featureform]

**"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.[^huyen2023][^tecton2025]

## Critiques

Not every team needs a feature store, and the category has its skeptics. Three lines of critique recur:

- **The build-versus-buy gap is real.** A managed feature store can cost more in licence and infrastructure than the engineering it replaces, especially for teams with two or three production models. Eugene Yan's "hierarchy of needs" framing makes this point: most organisations only need the bottom layers (access and serving) and can satisfy them with a warehouse and a key-value cache.[^applyingml]
- **The label has been used loosely.** Some products marketed as feature stores are essentially metadata catalogues without real serving guarantees, and others are basically warehouses with an SDK. The lack of a precise definition makes it easy for vendors to claim the term and hard for buyers to compare.[^huyen2023]
- **Vendor lock-in.** Once feature definitions are written in a vendor SDK and feature values flow through proprietary online stores, migrating is expensive. Open-source projects (Feast, Hopsworks, Chronon, Featureform) and lakehouse-native designs partly address this, but only partly.[^applyingml]

## Reference architectures

Three publicly documented designs are useful starting points for teams building or evaluating their own platform.

- **Uber Michelangelo (updated).** The original 2017 architecture has been extended over the years with Palette (the feature store), Manifold (interpretation), and Gallery (model serving). The dual batch/streaming feature model with Hive offline and Cassandra online remains the template most other systems use.[^uber2017]
- **Tecton feature platform.** Tecton splits the architecture into definitions (Python feature views in Git), a control plane (orchestration of materialisation jobs), and a data plane (offline store on the customer's warehouse plus an online store managed by Tecton).[^tecton2025]
- **Feast 0.x.** The Feast architecture document distinguishes the registry (a metadata file), the offline store (one of many warehouses), the online store (one of many key-value stores), and the SDK that orchestrates them. Crucially, Feast does not run computation itself; it pushes work down to the warehouse, the streaming engine or the user's own ETL.[^feast]

## Software ecosystem

The principal feature stores in production today are:

- **Feast** (open source, Apache 2.0; LF AI & Data Foundation)[^feast]
- **Tecton** (commercial; part of Databricks since 2025)[^databrickstecton]
- **Hopsworks** (Logical Clocks; open core with commercial editions)[^hopsworks]
- **Databricks Feature Engineering** (formerly Databricks Feature Store)[^databricks2021][^databricksrelease]
- **Amazon SageMaker Feature Store** (AWS managed)[^aws2020]
- **Vertex AI Feature Store** (Google Cloud managed)[^vertex2023]
- **Azure ML managed feature store** (Microsoft managed)[^azure2023]
- **Featureform** (open source MPL 2.0; part of Redis)[^featureform]
- **Chronon** (Apache 2.0; Airbnb and Stripe)[^chronon2024]

Feature stores are part of the broader [MLOps](/wiki/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.

## References

[^uber2017]: 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/

[^feastgcp2019]: 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

[^gojek]: Gojek Engineering. "Feast: Bridging ML Models and Data." https://www.gojek.io/blog/feast-bridging-ml-models-and-data

[^feast]: 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).

[^tectonlaunch]: 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

[^tectonseriesb]: 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

[^tectonseriesc]: Tecton blog (12 July 2022). "Tecton Raises $100M in Series C Funding." https://www.tecton.ai/blog/tecton-raises-100m-in-series-c-funding/

[^tcrunch2022]: 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/

[^databrickstecton]: 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

[^tecton2025]: Tecton product documentation (2025). https://docs.tecton.ai/

[^aws2020]: 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/

[^awsblog2020]: 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/

[^databricks2021]: 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

[^databricksrelease]: "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

[^vertex2023]: 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

[^azure2023]: 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

[^chronon2024]: 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

[^logicalclocks2020]: 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

[^hopsworks]: Hopsworks documentation and product page. https://www.hopsworks.ai/

[^featureform]: Featureform documentation and GitHub. https://www.featureform.com and https://github.com/featureform/featureform (MPL 2.0; acquired by Redis).

[^huyen2023]: 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

[^aerospike2024]: Aerospike (2024). "Feature Store 101: Build, Serve, and Scale ML Features." https://aerospike.com/blog/feature-store/

[^applyingml]: Yan, E. "Feature Stores: A Hierarchy of Needs." Applying ML resources. https://applyingml.com/resources/feature-stores/