docs: add blog post on experimental feature view versioning support

Agent-Logs-Url: https://github.com/feast-dev/feast/sessions/73d0759c-d919-4a07-92ca-7069692b1346 Co-authored-by: franciscojavierarceo <4163062+franciscojavierarceo@users.noreply.github.com>
franciscojavierarceo · Apr 1, 2026 · Mar 31, 2026 · Mar 31, 2026 · Mar 31, 2026 · Mar 31, 2026
commit 69f69410e3c710e7a98fae9130aea085bedb69c3
diff --git a/docs/blog/README.md b/docs/blog/README.md
@@ -19,3 +19,7 @@ Welcome to the Feast blog! Here you'll find articles about feature store develop
 {% content-ref url="rbac-role-based-access-controls.md" %}
 [rbac-role-based-access-controls.md](rbac-role-based-access-controls.md)
 {% endcontent-ref %}
+
+{% content-ref url="feature-view-versioning.md" %}
+[feature-view-versioning.md](feature-view-versioning.md)
+{% endcontent-ref %}
diff --git a/docs/blog/feature-view-versioning.md b/docs/blog/feature-view-versioning.md
@@ -0,0 +1,198 @@
+# Feast Introduces Experimental Feature View Versioning 🚀
+
+*March 31, 2026* | *Francisco Javier Arceo*
+
+## Overview
+
+We are excited to announce the experimental release of **Feature View Versioning** in Feast — a long-requested capability that brings automatic version tracking, safe rollback, and multi-version online serving to your feature store.
+
+This feature is still **experimental** and we would love to hear your feedback. Try it out and let us know what works, what doesn't, and which online stores you'd like to see supported next.
+
+## Why Feature Versioning Matters
+
+In practice, feature views evolve constantly. Data scientists add new features, rename columns, change transformation logic, or swap data sources. Today, every `feast apply` silently overwrites the existing definition — with no record of what it looked like before.
+
+This creates three persistent pain points:
+
+1. **No audit trail.** Teams struggle to answer "what did this feature view look like last week?" or "when was this schema changed and by whom?"
+2. **No safe rollback.** If a schema change breaks a downstream model, the only recourse is to manually reconstruct the old definition — often from memory or version control history.
+3. **No multi-version serving.** During a migration, Model A might rely on the old feature schema while Model B needs the new one. Without versioning, serving both simultaneously requires duplicating the entire feature view under a different name.
+
+## How It Works
+
+Version tracking is fully automatic. You don't need to change anything about how you write or apply feature views:
+
+```bash
+feast apply                  # First apply → saved as v0
+# ... edit schema ...
+feast apply                  # Detects change → saved as v1
+feast apply                  # No change detected → still v1 (idempotent)
+# ... edit source or UDF ...
+feast apply                  # Detects change → saved as v2
+```
+
+Every time `feast apply` detects a real change to a feature view's schema or transformation logic, it automatically saves a versioned snapshot to the registry. Metadata-only changes (description, tags, TTL) are updated in place without creating a new version.
+
+### What Gets Versioned
+
+- Changes to the feature schema (adding, removing, or renaming fields)
+- Changes to batch or stream data sources
+- Changes to on-demand feature view UDFs
+- Any other structural change that affects data layout or derivation
+
+### What Does Not Trigger a New Version
+
+- Tag or description updates
+- TTL changes
+- Re-applying an identical definition (idempotent behavior)
+
+## Exploring Version History
+
+You can list all recorded versions of a feature view from the CLI:
+
+```bash
+feast feature-views list-versions driver_stats
+```
+
+```
+VERSION  TYPE          CREATED              VERSION_ID
+v0       feature_view  2026-01-15 10:30:00  a1b2c3d4-...
+v1       feature_view  2026-01-16 14:22:00  e5f6g7h8-...
+v2       feature_view  2026-01-20 09:15:00  i9j0k1l2-...
+```
+
+Or programmatically:
+
+```python
+store = FeatureStore(repo_path=".")
+versions = store.list_feature_view_versions("driver_stats")
+for v in versions:
+    print(f"{v['version']} created at {v['created_timestamp']}")
+```
+
+## Multi-Version Online Serving
+
+When `enable_online_feature_view_versioning: true` is set in your `feature_store.yaml`, you can read features from a specific version using the `@v<N>` syntax:
+
+```yaml
+registry:
+  path: data/registry.db
+  enable_online_feature_view_versioning: true
+```
+
+```python
+online_features = store.get_online_features(
+    features=[
+        "driver_stats:trips_today",           # latest version (default)
+        "driver_stats@v1:trips_today",        # read from v1
+        "driver_stats@v2:avg_rating",         # read from v2
+    ],
+    entity_rows=[{"driver_id": 1001}],
+)
+```
+
+Multiple versions can be queried in a single call, making gradual migrations straightforward: keep serving the old version to existing consumers while routing new consumers to the latest.
+
+### Online Store Table Naming
+
+- v0 continues to use the existing, unversioned table (e.g., `project_driver_stats`) — fully backward compatible
+- v1 and later use suffixed tables (e.g., `project_driver_stats_v1`, `project_driver_stats_v2`)
+
+Each version requires its own materialization:
+
+```bash
+feast materialize --views driver_stats --version v2 <start_date> <end_date>
+```
+
+## Safe Rollback
+
+You can pin a feature view to a specific historical version by setting the `version` parameter. `feast apply` will replace the active definition with the stored snapshot:
+
+```python
+# Revert to v1 — restores schema, source, and transformations from the v1 snapshot
+driver_stats = FeatureView(
+    name="driver_stats",
+    entities=[driver],
+    schema=[...],
+    source=my_source,
+    version="v1",
+)
+```
+
+After running `feast apply`, the active feature view will match the v1 snapshot exactly. Remove the `version` parameter (or set it to `"latest"`) to resume auto-incrementing behavior.
+
+## Staged Publishing with `--no-promote`
+
+For breaking schema changes, you may want to publish a new version without immediately making it the default for unversioned consumers. Use the `--no-promote` flag:
+
+```bash
+feast apply --no-promote
+```
+
+This saves the version snapshot without updating the active definition. Unversioned consumers (`driver_stats:trips_today`) continue reading from the previous version, while opted-in consumers can start using `driver_stats@v2:trips_today` right away. When you're ready to make the new schema the default, run `feast apply` without the flag.
+
+## The Challenges of Correctness in Feature Versioning
+
+Feature versioning might sound simple in principle, but **getting it right is surprisingly hard**, especially for materialization.
+
+### The Core Tension
+
+Each version of a feature view may have a completely different schema, source, or transformation. This means:
+
+- Each version needs its own online store table with the right columns
+- Materializing one version must not corrupt data in another version's table
+- Version-qualified online reads must resolve the snapshot at the right point in time before looking up the online table
+- The active (promoted) version and historical snapshots must stay consistent
+
+### Materialization Complexity
+
+Today, running `feast materialize` without specifying a version fills the **active** version's table. To populate a historical version's table, you must explicitly pass `--version v<N>` so Feast can reconstruct the schema from the saved snapshot and target the correct online table.
+
+This matters for correctness: if you apply v2 of a feature view (which drops a column) and then run an unversioned `feast materialize`, the v1 online table is not automatically backfilled or maintained. Teams need to think carefully about which versions they want to keep materialized and for how long.
+
+### Tradeoffs
+
+| Concern | Tradeoff |
+|---|---|
+| Storage cost | Each active version requires its own online table — storage scales with the number of versions kept live |
+| Operational complexity | Teams must manage materialization schedules per version |
+| Consistency windows | Because each version has its own materialization job, two versions of the same feature for the same entity may have different freshness |
+| Concurrency | Two simultaneous `feast apply` calls can race on version number assignment — the registry backends use optimistic locking to handle this, but teams should be aware |
+
+These tradeoffs are real and we're still refining the model based on community experience. We've tried to make the defaults safe (versioning is opt-in for online reads, backward compatible for unversioned access) while giving teams the controls they need.
+
+## Current Limitations
+
+This is an experimental feature and there are known gaps:
+
+- **Online store support** — Version-qualified reads (`@v<N>`) are **SQLite-only** today. We plan to add Redis, DynamoDB, Bigtable, Postgres, and others based on community demand. If you need a specific store, [open a GitHub issue](https://github.com/feast-dev/feast/issues/new) and let us know.
+- **Offline store versioning** — Versioned historical retrieval is not yet supported.
+- **Version deletion** — There is no mechanism today to prune old versions from the registry.
+- **Feature services** — Feature services always resolve to the active (promoted) version. `--no-promote` versions are not accessible through feature services until promoted.
+
+## Supported Feature View Types
+
+Versioning works across all three feature view types:
+
+- `FeatureView` (and `BatchFeatureView`)
+- `StreamFeatureView`
+- `OnDemandFeatureView`
+
+## Getting Started
+
+1. Upgrade to the latest version of Feast.
+2. Add `enable_online_feature_view_versioning: true` to your registry config in `feature_store.yaml` (only needed for versioned online reads).
+3. Run `feast apply` as usual — version history tracking starts automatically.
+4. Explore your version history with `feast feature-views list-versions <name>`.
+
+For full details, see the [Feature View Versioning documentation](../reference/alpha-feature-view-versioning.md) and the [Feature View Versioning RFC](../rfcs/feature-view-versioning.md).
+
+## Share Your Feedback
+
+We want to hear from you! Try out feature view versioning and tell us:
+
+- Which online stores you need supported next
+- Which workflows feel awkward or incomplete
+- How the materialization model fits your real-world pipelines
+
+Join the conversation on [GitHub](https://github.com/feast-dev/feast/issues) or in the [Feast Slack community](https://slack.feast.dev/). Your feedback directly shapes what we build next.