Repository navigation
Improved feature view and model versioning #2728
Description
Problem
When using Feast, it can be hard to version features with respect to models in production.
- Users modifying a re-used feature view (e.g. in response to upstream schema change) can accidentally impact other models in production
- Hard to tie versions of features together or versions of models (~
FeatureService)
As Feast adds batch transformations or #2597, transformation logic will also need to be versioned. This is already an issue today with on demand feature views too.
Potential solution
One way to address this is to double down on:
1. Feature services as the central way to retrieve features + track models.
- Registering a feature service signifies dependent features / feature views are in "production"
- Allow
feature_service.get_historical_featuresorfeature_service.get_online_features
2. Improvements to feast plan and feast apply
feast planthat prevents deletion or editing of feature views that feature services in prod depend on (Modifying https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L594)- If you remove a feature service, then the underlying feature views could be removed if no other feature service depend on it
feast applythat fails in above case by default (overridable though)- e.g. modifying the logic at https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L676
3. Feature view versioning
- Not super sure here on the best practice, but a way to say that feature view B is a new version of feature view A.
Reacted by Keith Adler, Shane Keller, davidschuler-8451, Breno Costa, Francisco Javier Arceo, andersonchung618 and Yassin Nouh
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
stale commentedon Sep 22, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
20 remaining items
franciscojavierarceo commentedon Mar 29, 2026
Keeping this open until all sub issues are closed for online stores.
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
docs: add link to original issue #2728 in feature-view-versioning blo…
docs: Add blog post on experimental feature view versioning support (#…
docs: Add blog post on experimental feature view versioning support (f…
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
feat: Add feature view versioning support to PostgreSQL and MySQL onl…
chore(release): release 0.61.0
chore(release): release 0.62.0
sauravsingla commentedon Sep 25, 2026
A related concern here is behavioral compatibility, not only structural/version compatibility.
A new feature-view or feature-service version can be schema-compatible and still change downstream model decisions for a meaningful subset of entities. I maintain an open-source project called DeciShift that compares two executable versions of an ML decision system at the final-action level and can attribute differences across features, models, thresholds, policies, and rules.
One Feast-oriented pattern that seems useful would be:
FeatureService/version A → model/decision flow Avs.
FeatureService/version B → model/decision flow Brun on the same entity/evaluation set, followed by checks on action transitions plus global and cohort-level decision-shift thresholds.
That could complement
feast plan/feast apply: those protect the registry/dependency structure, while a downstream behavioral regression check would test whether a seemingly valid feature change actually alters operational decisions unexpectedly.If this is useful to the project, I’d be interested in putting together a small public-data Feast + DeciShift example to test the idea.