Feature Stores: Feast and Tecton — MLOps & Model Deployment

Features, the engineered signals a model consumes, are usually computed twice in an organisation: once in batch for training and again in a service for live predictions, and those two implementations inevitably drift apart, producing the single most insidious bug in production ML, training-serving skew. Feature stores exist to end this duplication by becoming the central system that defines, computes, stores, and serves features consistently to both training and inference. They emerged at companies like Uber, whose Michelangelo introduced the concept, because teams kept rebuilding the same features, reusing none, and silently shipping models whose live inputs differed from their training inputs. A feature store gives features the same first-class, discoverable, versioned status that data warehouses gave tables. The result is reuse across teams, guaranteed consistency between offline and online paths, and the ability to fetch fresh feature values at low latency for real-time models that cannot afford to recompute everything per request.

Analogy🏏Cricket

🏏 Think of it like cricket: imagine a batting coach analysing why Virat Kohli scored freely in one innings but struggled in another, yet kept no notes on which bat, which guard, or which net drills preceded each. Just as a detailed training diary logging bat weight, stance, and bowling type lets the coach link inputs to outputs, MLflow logs hyperparameters and data to outcomes. Just as comparing diary entries reveals that a heavier bat hurt timing, comparing tracked runs reveals which learning rate lifted accuracy. Just as a shared diary lets the whole support staff learn from one session, a shared tracking server lets the whole team learn from every run. The insight is that improvement is impossible without recorded cause and effect; tracking is what converts trial and error into knowledge.