Feature Stores: A Hierarchy of Needs — Eugene Yan

Summary

Yan applies Maslow’s hierarchy of needs to feature stores, arguing that teams should satisfy foundational needs before reaching for advanced capabilities:

1. Access (base) — documented features with transparency into logic/code and lineage to upstream sources. Enables discovery, sharing, and reuse.
2. Serving — features available in production at high throughput and low latency, with offline-to-online sync.
3. Integrity — point-in-time correctness (time travel) to prevent data leakage in training sets. Monitoring of model performance.
4. Convenience — interactive exploration and experimentation with features.
5. Autopilot (top) — automated backfilling, alerting, and self-healing.

The mental model: don’t build serving infrastructure before you’ve solved feature discovery. Don’t automate what you haven’t validated.

Relevance

Maps directly to 06-reference/2026-03-31-block-hierarchy-to-intelligence — both articles argue for layered capability building where each layer depends on the one below. The feature store hierarchy is a domain-specific instance of the general pattern.

Connects to 06-reference/2026-04-03-data-products-taxonomy — feature stores are Weber’s “ML platform” data product, and this hierarchy shows that even within one data product category, there’s a maturity sequence.

For 01-projects/phdata/index, this is a useful framework for scoping ML infrastructure engagements: assess where the client sits on the hierarchy and build the next layer, not the top layer. Also relevant to 01-projects/phdata/career-transition — demonstrates systems thinking about ML infrastructure.

The access layer (documentation, lineage, reuse) connects to 06-reference/concepts/compounding-knowledge — feature reuse is knowledge compounding in infrastructure form. Also resonates with 06-reference/2026-04-03-combining-rule-engines-ml — the integrity layer (preventing data leakage) matters most when combining rule-based and ML approaches.

Open Questions

• Where does a Snowflake-native feature store (Snowpark + dynamic tables) sit vs. purpose-built tools like Feast or Tecton?
• Ray’s note about batch inference — does a batch-only workflow let you skip the “serving” layer and jump to integrity?
• How does the feature store hierarchy interact with the headless BI metrics layer (06-reference/2026-04-03-headless-bi)? Are features and metrics converging?