Feature store

A feature store is a centralized system that computes, stores, and serves ML features consistently between training and inference — eliminating training/serving skew. Tecton, Feast, Hopsworks, Databricks Feature Store are 2026 examples.

Training and serving features from separate pipelines is a footgun: subtle implementation differences cause training/serving skew, models work in dev and fail in prod. Feature stores fix this with one definition reused everywhere: declare a feature (e.g., 'user 7-day order count'), the store computes it offline for training data and online for inference, both reading from the same definition. By 2026 feature stores matter most for classical ML (recsys, fraud, churn); pure LLM apps care less because their 'features' are prompts + retrieved context. But hybrid LLM + ML stacks (recommendations with LLM rerank, fraud detection with LLM explanations) bring feature stores back into the picture.

When to use feature store

• Classical ML in production (recsys, fraud, ads).
• Hybrid ML + LLM systems sharing features.

Common mistakes

• Adding a feature store when raw queries work fine — premature complexity.

FAQ

Related terms

• Experiment tracking — Experiment tracking is the MLOps discipline of capturing hyperparameters, metrics, model artifacts, and code versions per training run — making model development reproducible and comparable. W&B, Comet, MLflow, Neptune are 2026 leaders.
• Model registry — A model registry is the versioned store for trained model artifacts + metadata — the source of truth for which model version is in staging vs prod, what its eval scores were, and how to roll back. MLflow, W&B, Sagemaker, Vertex AI all ship one in 2026.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/feature-store.md.