Feature Stores

Centralized service for computing, storing, and serving features for both training and inference — eliminates training-serving skew and enables feature reuse. Feast (OSS), Tecton (commercial), Hopsworks, SageMaker FS, Vertex FS, Databricks FS.

Overview

What a feature store is

A feature store computes, stores and serves ML features consistently to two consumers: the training pipeline (offline) and the inference service (online). It exists to solve one critical problem, training-serving skew, and then earns its keep through feature reuse across teams and models.

The core problem: training-serving skew

Skew is the most common ML production failure. A data scientist computes "average transaction value over 30 days" in warehouse SQL; an engineer re-implements it with streaming aggregations. Small differences in window boundaries, timezone handling or null semantics make the two disagree by a few percent.

> [!WARNING] The gap is nearly invisible in logs, because no one compares feature values across the two environments.

Architecture: four components

  • Feature definition registry — Feature logic as versioned, shared code (Python decorator, SQL transform or YAML spec) — Stored in the feature store
  • Offline store — Historical feature values for training and batch scoring — BigQuery, Snowflake, Delta Lake, Iceberg on S3
  • Online store — Latest feature values at single-digit-millisecond reads — Redis, DynamoDB, Bigtable, Cassandra
  • Materialization engine — Computes features and writes both stores consistently — Batch: Spark, dbt. Streaming: Flink, Spark Streaming

Point-in-time correctness

When a model trains on a label event from 14 days ago, every feature joined to it must be the value as it was then, not today's value. A naive join leaks future information; the model looks great on the test set, then collapses in production.

> [!NOTE] This as-of join is the technical heart of feature store design, and why the offline store keeps timestamped history instead of overwriting values.

The 2026 vendor landscape

  • Feast (OSS) — Originated at Gojek in 2018, open-sourced 2019 — You supply the offline and online stores
  • Tecton (commercial) — Founded by the Uber Michelangelo team — Managed infra, sub-50ms serving, streaming, built-in monitoring
  • Hopsworks — Open-core — Strong for regulated and on-premises deployments
  • Databricks, Vertex AI, SageMaker Feature Store — Cloud-native — Default for teams committed to those platforms

When to use one

  • Multiple models share features — One team, one batch model, three features
  • Online inference at high QPS with latency SLOs — No online serving
  • Streaming features must stay consistent — No cross-team reuse
  • Several teams need shared governance

> [!TIP] The boundary: more than one team with more than one online model.

Interview questions

  • Explain training-serving skew. Why does it happen and how does a feature store prevent it?
  • How does point-in-time correctness work and what happens if it is violated?
  • Compare Feast, Tecton, and cloud-native feature stores. When would you choose each?
  • How would you design a feature store for a real-time fraud detection system serving 10,000 QPS?
  • What is the difference between batch materialization and streaming features, and when does each apply?

Sign up free to read the full topic

More MLOps & LLMOps topics

Start free on Cariara · Coding problems · System design studio