Feature Stores for Research

When several researchers each compute their own version of "12-month momentum" or "earnings surprise," small differences in windowing, lagging, or handling of missing data creep in — and results stop being comparable across the team, or worse, a signal that looked robust turns out to differ subtly between someone's backtest and the production pipeline. A feature store is a shared, versioned repository where features are computed once, by one agreed definition, and then reused by everyone: a researcher pulls "momentum_12m_v3" from the store rather than recomputing it from raw prices each time.

Feature stores typically track point-in-time correctness (guaranteeing a feature's value as of any past date reflects only data available at that time), version history (so a strategy can be pinned to "v3" of a feature even after "v4" is released), and lineage (which raw data and transformation produced a given feature value).

Worked example

A researcher builds a strategy using a "quality" feature pulled straight from the shared store, dated correctly so that a company's Q2 earnings only enter the feature after its actual public filing date. Six months later, a data vendor restates historical earnings; the feature store recomputes and versions the update as "quality_v2" without silently overwriting "quality_v1," so the original backtest remains exactly reproducible even after the underlying data changed.

Without a feature store, this kind of restatement often silently changes every researcher's ad hoc recomputation of the same signal, making old backtests impossible to reproduce and new ones hard to compare against them.