Feature Stores

Trading firms often compute the same feature — say, a stock's 20-day realized volatility — separately for research (in a Python notebook, using a historical snapshot) and for production (in a live trading engine, using streaming data), and small differences between the two implementations quietly create a mismatch between what a backtest measured and what the live strategy actually sees. A feature store solves this by making feature computation a single, versioned, shared service: a feature is defined once, computed on a schedule or on demand, stored with its exact timestamp, and served identically to both offline research jobs and the live trading system, so there's no chance the two disagree on what "20-day realized volatility as of last Tuesday" actually was.

Feature stores also typically track point-in-time correctness automatically, refusing to serve a feature value using data that wouldn't have been available yet at that historical timestamp, which is one of the most common sources of look-ahead bias in backtests built by hand.

Beyond consistency, a feature store also gives a team reuse: once a feature like "20-day realized volatility" is defined and registered, any other researcher or strategy can pull the same value rather than re-implementing (and possibly subtly mis-implementing) the same calculation. Most production feature stores also cache computed values, so an expensive feature doesn't need to be recomputed from raw data every time a new model wants to use it, which matters when dozens of models share overlapping sets of underlying features.