March 31, 2026 · 4 min read
A Feature Store Wasn't Worth Adopting Yet, Here's Why
A feature store solves real problems at real scale, and we almost adopted one for a team that didn't have those problems yet. Here's the line I now use to decide.
A team I worked with had two models in production and a roadmap for three more, and someone on the team — reasonably, from the conference talks and blog posts everyone reads — proposed adopting a feature store before building the next model. It's the kind of infrastructure that sounds like the responsible, mature-engineering-org choice. We scoped it, priced the setup and maintenance cost, and killed it.
What a feature store actually solves
A feature store earns its complexity when you have the same features being computed and consumed by multiple models, when training-serving skew from inconsistent feature computation is an active, recurring problem, and when feature freshness requirements are tight enough that ad hoc pipelines can't keep up. None of those were true for us. Two models, minimal feature overlap between them, batch scoring with no low-latency serving requirement.
A feature store is a solution to feature reuse and consistency at scale. Adopting it before you have either is paying maintenance cost for a problem you don't have.
What we built instead
A shared feature computation module — plain code, version controlled, imported by both the training pipeline and the serving pipeline so the same function computes the same feature the same way in both places. That's the actual problem a feature store solves at our scale, solved without the operational overhead of a dedicated system that needed its own infrastructure, its own on-call awareness, and its own learning curve for a two-person ML team.
- Training-serving skew: solved by a shared feature computation function, not a feature store.
- Feature reuse across models: didn't exist yet with only two models in production.
- Low-latency serving requirements: didn't exist, everything was batch.
- Team size and maintenance capacity: too small to own another piece of infrastructure well.
The honest version of this post isn't "feature stores are overrated" — they solve a real problem well once you're past a certain scale and model count. The honest version is that infrastructure maturity should follow problems you actually have, not problems you're worried about having eventually, and most teams I've seen adopt a feature store were solving the second kind.