Skip to content
ROOT
STUB

Feature Store

The pattern: define features once; serve them at training (offline, point-in-time-correct) and at inference (online, low-latency). The same definition, two materializations. Solves train-serve skew structurally and unlocks feature reuse, freshness SLOs, lineage, and governance as platform-level concerns.

The trade-off: infrastructure complexity vs. skew prevention. A feature store is real infrastructure — offline store, online store, registry, materialization scheduler. For a single-model team, the overhead rarely pays off. For a platform hosting many models with shared features, one definition shared across ten consumers — with the same correctness guarantees on both sides — is the entire point.

Deepens in Year 4 Phase 22: Feature Store — Feast on Iceberg with a Redis online store, defining commits-per-repo features for personal-api consumers. Reinforced in Phase 25: GPU Infrastructure when drift detection closes the loop.

  • train-serve-skew — the failure mode this pattern exists to prevent.
  • model-lifecycle — the lifecycle stages that consume offline and online feature views.
  • inference-shapes — online vs. batch consumption maps onto the two materializations.
  • snapshot-plus-delta — point-in-time correctness on the offline side leans on this.
  • oltp-vs-olap — online (OLTP-shaped key lookup) vs. offline (OLAP-shaped scan) is the underlying split.
  • tool-use-as-capability — common backing store behind retrieval tools.
  • Phase 24: LLM Infra + RAG — vector index alongside feature store for hybrid retrieval.
  • basecamp — where Feast lives in the platform stack.
  • mlship — consumer of online features at inference time.