Guides

How to choose a feature store

The real choice is whether your cloud or warehouse already has one built in, and whether you need sub-millisecond serving or just a shared registry.

4Analytics · Published September 22, 2026

A feature store exists to solve one specific problem: keeping the input values a machine learning model was trained on consistent with the values it sees in production. A model trained on "average order value over the last 30 days" computed one way, served in production by code computed a slightly different way, degrades silently — no error, just a model that performs worse than its offline evaluation promised. A feature store separates the definition of a feature from where it is computed, keeps an offline store for point-in-time-correct training data and an online store for low-latency inference, and lets both pull from the same definition. If your team is not yet running models in production against features computed by more than one pipeline, you likely do not need one yet; the discipline of a shared data pipeline and consistent transformations matters more at that stage than the store itself.

Check what your platform already gives you for free

Before evaluating a standalone product, check whether the platform you already run has this built in, because for most teams it does. Databricks Feature Store is not a separate purchase — since Unity Catalog became the feature store, any Delta table with a primary key can act as one, inheriting Databricks' existing governance and billed as ordinary Databricks compute. Amazon SageMaker Feature Store and Vertex AI Feature Store work the same way inside AWS and Google Cloud respectively: a module of a platform you are likely already paying for, not a distinct line item. If your team is already standardized on one of these three, the honest first question is not "which feature store" but "why would we add a fourth vendor when this one is already inside our bill."

Decide if you need a vendor-neutral, self-hosted option

Feast is governed by the Linux Foundation rather than owned by a single vendor, and it is a registry and serving layer, not a compute engine — it does not transform data itself, it manages definitions and materializes them into an online store (Redis, DynamoDB and others) from data you have already engineered elsewhere. That makes it the right fit for teams who want a lightweight, cloud-agnostic layer on top of a feature-engineering pipeline they already run, and who specifically do not want to be tied to one cloud's feature-store module. Hopsworks goes further than a registry: it includes its own compute for feature pipelines (Spark, Python, Flink) plus a model registry and model serving in the same platform, with a genuine self-hosted or air-gapped Enterprise edition — the option to consider if on-premises or regulatory constraints rule out a cloud-hosted feature store entirely.

Decide how much you need to change to adopt it

Featureform — now developed by Redis as Redis Feature Form since its October 2025 acquisition — markets itself as a "virtual" feature store: it orchestrates feature definitions and serving on top of infrastructure you already run (Snowflake, Databricks, Spark, Postgres) rather than requiring you to migrate data into a new system. That is a meaningfully lower-friction adoption path than a platform that wants to own storage outright, at the cost of depending on Redis's roadmap for the product going forward, since it is no longer an independent open-source project.

Decide how low your latency needs to go

Most feature stores serve production inference in tens of milliseconds, which is fine for most models. Chalk is built specifically for the sub-5ms end of the market — fraud detection, underwriting, real-time recommendations — where feature computation itself, not just lookup, has to happen inline with a request. It compiles feature definitions written in Python into pipelines that run across streaming, batch and on-demand contexts from the same source, and it deploys inside your own cloud account rather than being fully vendor-hosted. If your use case tolerates normal serving latency, this is more platform than you need; if it does not, none of the platform-bundled options were built for it.

Deployment and governance

Every option here except the three cloud-native modules can be self-hosted to some degree, but "can" and "designed for" differ: Feast and Hopsworks are genuinely built to run on your own Kubernetes cluster; Chalk deploys into your cloud account by design, trading full vendor hosting for data staying inside your own environment; Featureform sits on top of infrastructure you already operate. If data residency, air-gapping or avoiding a fourth cloud vendor is a hard requirement, that alone narrows the field to Feast, Hopsworks or Chalk.

How pricing scales

The three cloud-native feature stores are not sold separately — they are billed as ordinary usage of the platform they live inside (Databricks compute and Unity Catalog storage; AWS usage for SageMaker; Vertex AI and BigQuery usage for Google Cloud), so there is no separate feature-store price to compare. Feast is free, open-source software with no vendor product to buy — you pay for the infrastructure it runs on. Hopsworks has a free single-project tier, pay-as-you-go SaaS, and custom-quoted Enterprise for on-premises deployment. Chalk and Featureform are quote-only, sold through a sales conversation. Model cost against your actual feature volume and serving QPS rather than a list price — check each profile for verified figures.

A shortlist by situation

  • Already standardized on Databricks: Databricks Feature Store.
  • Already standardized on SageMaker: Amazon SageMaker Feature Store.
  • Already standardized on Vertex AI and BigQuery: Vertex AI Feature Store.
  • Want a vendor-neutral registry over an existing feature-engineering pipeline: Feast.
  • Want a feature store, model registry and model serving together, with a real self-hosted option: Hopsworks.
  • Want to add governance over infrastructure you already run, without migrating data: Featureform.
  • Need sub-5ms feature computation and serving for fraud, underwriting or real-time recommendations: Chalk.

Questions to ask vendors or in a trial

  1. Does this feature store compute features, or only register and serve definitions computed elsewhere?
  2. What is measured serving latency under our real query pattern, not an idle benchmark?
  3. If we are already paying for a cloud ML platform, what does this add beyond what is already included?
  4. How does point-in-time correctness actually get enforced when a feature definition changes?
  5. What does self-hosting cost in engineering time versus the managed or bundled option?

Common mistakes

Adopting a standalone feature store before checking whether the ML platform already in use provides one for free. Choosing based on serving-latency numbers that do not match the actual use case — most teams do not need sub-5ms serving and are paying for capability they will not use. And treating a feature store as a substitute for feature-engineering discipline: it keeps training and serving consistent, but it does not decide which features are worth computing in the first place.

See Databricks Feature Store vs SageMaker Feature Store and Feast vs Hopsworks for two direct match-ups, and browse every tool in this category.

Related tools

Chalk Real-time feature platform that computes and serves ML features from Python definitions, deployed inside the customer's own cloud. Databricks Feature Store Feature registry and serving layer built into Databricks Unity Catalog, using Delta tables as feature tables. Feast Open-source feature store that manages feature definitions, storage, and serving so ML models get consistent features in training and production. Featureform Virtual feature store that turns existing data infrastructure into a governed feature store; now developed by Redis as Redis Feature Form. Hopsworks Feature store and MLOps platform pairing a governed feature store with model registry and serving, available self-hosted or as SaaS. Amazon SageMaker Feature Store Fully managed feature repository inside SageMaker that stores, discovers and serves ML features for training and inference.

Terms used in this guide

Feature store A centralized system that stores, versions and serves machine learning features so training and live prediction use identical definitions. Machine learning Building models that learn patterns from data to make predictions or decisions, rather than following hand-coded rules. Feature engineering Creating, transforming or selecting the input variables a model is trained on, to make the underlying pattern easier for it to learn. Data pipeline The automated sequence of steps that moves data from source systems to a destination, transforming it along the way. MLOps (machine learning operations) The set of practices for deploying, monitoring and maintaining machine learning models reliably in production, extending DevOps to ML systems.

Latest on this topic