2026-10-20 · AI in production
When a feature store pays off — criteria from running a GenAI platform
LLMOps checklists list the feature store as a standard component. For a multi-tenant GenAI platform I checked which problem it solves — and how to tell whether you have it.
Feast, Tecton, Vertex Feature Store: anyone building a “grown-up” AI platform finds these components on every architecture checklist. They come from classic machine learning, and that is exactly where the question lies.
What a feature store actually solves
It makes sure tabular features are computed the same way when training your own model and in production — offline and online, with point-in-time correctness so the model does not see the future during training. The problem only exists if you train your own models on tabular data.
What takes its role in an LLM system
On the platform, a system for content and PR analytics, LLMs decide through an API based on prompt and context. Reproducibility comes from two other components here: prompts are versioned in the database, and every LLM decision writes an immutable record — pipeline version, input snapshot and its SHA-256, verdict, tokens, cost, duration. For search by meaning there are embeddings in pgvector; that is a vector store, not a feature store.
A feature store today would have added another service, synchronisation and operations, but no benefit. I did not introduce it — and wrote down the criterion for revisiting the decision right away.
When it pays off
The trigger is the first in-house model on tabular data. Realistic candidates: a cheap classifier replacing part of the LLM fallbacks in topic clustering, choosing the crawling strategy per domain from success and cost history, scoring media and authors.
Even then the first step is not a new platform but a feature table in Postgres with an “as_of” timestamp. The decision log with its manual corrections is by then already a labelled dataset — built for audit and cost transparency. A dedicated feature store makes sense once there are several such models that need low-latency online serving.
The same rule applies to model registries and the rest: first clarify which problem the component solves, then check whether you have it.