Description

adchia

opened on May 23, 2022

Issue body actions

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_features or feature_service.get_online_features

2. Improvements to feast plan and feast apply

• feast plan that 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 apply that 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

Activity

1. adchia

   added

   kind/featureNew feature or requestNew feature or request

   priority/p1

   Community Contribution NeededWe want community to contributeWe want community to contribute

   on May 23, 2022
2. adchia

   added this to Feast Roadmapon May 23, 2022
3. adchia

   moved this to Todo in Feast Roadmapon May 23, 2022
4. adchia

   added

   kind/projectA top level project to be tracked in GitHub ProjectsA top level project to be tracked in GitHub Projects

   on May 24, 2022
5. adchia

   moved this from Todo to Upcoming in Feast Roadmapon May 24, 2022
6. adchia

   moved this from Upcoming to Todo in Feast Roadmapon Sep 2, 2022
7. stale commented on Sep 22, 2022

   

   staleBot

   on Sep 22, 2022

   More actions

   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.
8. stale

   added

   wontfixThis will not be worked onThis will not be worked on

   on Sep 22, 2022
9. stale

   closed this as completedon Oct 1, 2022
10. Repository owner moved this from Todo to Done in Feast Roadmapon Oct 1, 2022
11. adchia

    reopened this on Oct 1, 2022
12. adchia

    added

    keep-open

    and removed

    wontfixThis will not be worked onThis will not be worked on

    on Oct 1, 2022
13. 20 remaining items
14. franciscojavierarceo

    added a sub-issue on Mar 26, 2026

    • Add feature view versioning support to SingleStore online store #6181
15. franciscojavierarceo

    reopened this on Mar 29, 2026
16. franciscojavierarceo commented on Mar 29, 2026

    

    franciscojavierarceo

    on Mar 29, 2026

    Member

    More actions

    Keeping this open until all sub issues are closed for online stores.
17. YassinNouh21

    added 4 commits that reference this issue on Mar 29, 2026

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    7fef18d

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    744eaa9

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    b35410f

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    0e56ae2
18. Copilot

    added a commit that references this issue on Apr 1, 2026

    docs: add link to original issue #2728 in feature-view-versioning blo…

    ff32217
19. franciscojavierarceo

    added a commit that references this issue on Apr 1, 2026

    docs: Add blog post on experimental feature view versioning support (#…

    a623674
20. yuan1j

    added a commit that references this issue on Apr 2, 2026

    docs: Add blog post on experimental feature view versioning support (f…

    81f169a
21. ntkathole

    added 2 commits that reference this issue on Apr 6, 2026

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    bd35805

    feat: Add feature view versioning support to PostgreSQL and MySQL onl…

    940e0f0
22. franciscojavierarceo

    added 2 commits that reference this issue on Apr 7, 2026

    chore(release): release 0.61.0

    b374396

    chore(release): release 0.62.0

    beaa9a6
23. sauravsingla commented on Sep 25, 2026

    

    sauravsingla

    on Sep 25, 2026 – with ChatGPT Codex Connector

    More actions

    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 A

    vs.

    FeatureService/version B → model/decision flow B

    run 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.

Issue actions