Feature Store  ·  View 11 of 21  ·  Data

Registry and Value Data Model

Eleven tables, and one asymmetry that carries the entire point-in-time guarantee.

Editable source SVG draw.io All views
entity_type entity_type_id PK name (user, store, courier…) key_format registered_at feature_group group_id PK entity_type_id FK owner_team cadence sensitivity_class freshness_slo_s feature feature_id PK group_id FK name dtype default_value online / offline flags feature_version version_id PK feature_id FK transform_hash window_spec lifecycle_state published_at access_grant grant_id PK group_id FK principal purpose expires_at materialisation_run run_id PK group_id FK version_id FK engine window_closed_at status feature_value_offline entity_key PK feature_id PK event_ts PK ingest_ts value version_id FK run_id FK feature_value_online entity_key PK group_id PK value_map event_ts version_id FK ttl skew_measurement measure_id PK feature_id FK consumer_model sampled_at disagreement_rate verdict training_set set_id PK spine_uri snapshot_id lookback_s version_ids[] generated_at consumer_pin pin_id PK version_id FK consumer_model criticality absence_policy 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N stamps 1 : N projects as-of replayed read by Feature Store — Registry and Value Data Model Two timestamps on every offline value, one on every online value. That asymmetry is the whole point-in-time guarantee. Lineage is a graph, not a table, and lives in its own store. v 1.0 · owner Data Platform Architecture · date 2026-09

Decisions

  • Every offline value carries both an event timestamp and an ingestion timestamp. Every online value carries one. That asymmetry is the point-in-time guarantee, expressed as a schema.
  • Every value — offline and online — carries the definition version that produced it, which is what makes skew detectable and a definition/materialisation mismatch findable.
  • consumer_pin holds criticality and absence policy per consumer, not per feature, because the right failure mode for a fraud model is the wrong one for a ranking model.

Assumptions

  • Feature versions are immutable; a transformation, window or dtype change creates a new version and leaves pinned consumers on the old one.
  • Lineage is a graph workload and lives in its own store, so it is not modelled here.

Risks

  • An ingestion timestamp that a source cannot supply reliably makes a point-in-time join impossible for that feature. The platform refuses rather than approximates, which will be argued about.
◀  Storage Zones by Durability All views Critical Flow — An ETA Vector Read  ▶
Solution Architecture v1.0 · Amazon Web Services · Data Platform Architecture · 2026-09 · 21 views · 14 architecture decision records11-data-model