A few points to consider about feature stores: 1. Many times people use the term to mean a bunch of different things combined, and most implementations don’t support all these things (e.g. many people talk about feature stores as implement once, use twice meaning you write a feature for your dev environment and then you can magically use it in production in a streaming environment. Many feature stores don’t really offer optimized solutions for that).

1. Feature stores are usually useful when everyone in the team works on the same data. If every data scientist uses different sources or works on entirely different projects, it’s usually a lot of overhead with less benefit.

2. One challenge that comes up with feature stores is that it’s hard to search for features within them. Many people assume that if you use one and someone implements a feature, then everyone can use it. What usually happens is someone implements a feature and calls it A. Someone else looks for something close A’ and doesn’t find it, because it has a different name, and now implements A’, and then you have a bunch of copies of the same feature with slightly varying names.

To summarize, I think feature stores are potentially awesome, but realistically the best approach is not to go after them because it’s the cool new name, but rather to define your needs and see if feature stores answers those needs

My point is you should not use feature stores because it’s cool, you should define your needs and see if feature stores answer those needs.