In your use case is a feature store roughly a collection of incrementally updated feature tables + time/version meta?

We've been storing our features in RDBMS/normalized with each feature table having a run_id column (run_id is unique to pipeline version + timestamp of execution if batch processed; if streaming there is run_id for pipeline version but the date comes from interaction date, which is part of the raw data already]) and I'm curious what we're potentially missing..

In this sense you can query features for given users generated by particular version and/or date but it does involve potentially lots of joins (to get a collection of features).