The original pitch, and what changed
Feature stores – Feast, Tecton, Databricks Feature Store, Hopsworks – landed in 2019-2021 with a well-defined pitch. One place to define features once, use them in training and serving, avoid training-serving skew, share features across teams, manage point-in-time correctness for time-series data. For tabular ML at scale, that pitch was correct, and it is still correct.
What changed between 2022 and 2026 is the mix of models in production. A meaningful share of enterprise ML workloads has shifted from tabular classifiers to LLM-backed pipelines that do not consume "features" in the traditional sense. That shift has left a lot of teams confused about whether their feature-store investment is still paying off, or whether the whole category is quietly being replaced.
Where feature stores are still essential
For the workloads where feature stores always made sense – tabular classification, regression, ranking, recommendation, fraud detection, credit risk – the case has gotten stronger, not weaker. Three reasons.
- Regulatory scrutiny has increased. For financial-services, insurance, and healthcare pipelines, the feature-store's lineage and governance capabilities have become audit requirements, not nice-to-haves. Specifically, the ability to show which feature computation produced which training example on which date is now a table-stakes compliance ask.
- Point-in-time correctness is still hard. Training a credit model on features as they existed at decision time – not as they exist now – is still one of the easiest ways to silently leak data. Feature stores handle this with more discipline than most hand-rolled pipelines.
- Cross-team reuse still pays. The identity features, account-state features, and transactional features a fraud team builds are often the same ones a credit team needs. Without a feature store, that becomes duplicate pipelines and disagreeing values. With one, it becomes a governed asset.
Where LLMs partly displaced the feature store
The category of workloads LLMs have quietly eaten is narrower and more specific than most commentary suggests. It is mostly: moderately-complex tabular-plus-text pipelines where a lot of feature engineering used to be required to extract signal from free-text fields.
A support-ticket classifier in 2020 required a feature pipeline that tokenised the ticket body, computed TF-IDF, extracted named entities, joined customer metadata, and fed a gradient-boosted model. In 2026, a competent VLM or LLM with a typed output schema and a modest retrieval layer does the same job with less feature-engineering investment. The feature store in this pipeline shrinks to customer metadata, account state, and a thin summary of historical behaviour – which is still useful, but much less than it was.
The same shift shows up in product-recommendation pipelines (where embeddings partly replace hand-engineered features), intent detection, and many extraction workloads. The feature store has not disappeared from these; it has been pushed back to handling the structured-data portion of a now-hybrid pipeline.
What LLM pipelines need that feature stores do not yet do well
The more interesting gap is the other direction: LLM and RAG pipelines have their own "feature store-shaped" problems that classic feature stores are not yet solving elegantly.
- Embedding lifecycle. Re-embedding a corpus when you change models is painful. Knowing which embedding belongs to which source version, across retraining cycles, is an emerging governance problem that most teams handle with bespoke tooling.
- Prompt and template versioning. System prompts, few-shot examples, and output schemas are the "features" of an LLM pipeline. They need the same versioning, test, and governance discipline that features got in 2020 – and most teams do not have it.
- Retrieval recipe lineage. Which retrieval strategy (hybrid, reranker, contextual, GraphRAG) was used to produce which answer during which experiment? This is a genuine feature-store-equivalent problem that nobody has standardised on yet.
- Evaluation set management. LLM eval sets are a governed asset – versioned, permissioned, split into training-free holdouts. The tooling for this is less mature than feature-store tooling was three years in.
The pragmatic 2026 architecture
Most enterprise teams we advise have converged on a two-plane architecture. A traditional feature store handles the structured-data plane: tabular features, point-in-time correctness, feature-level lineage, feature sharing across models. A separate set of tools – often bespoke, sometimes evolving feature-store offerings – handles the LLM-pipeline plane: embeddings, prompts, retrieval configurations, eval sets.
The tools that are growing fastest in 2026 are the ones that recognise both planes exist and converge them at the metadata layer. Unity Catalog, DataHub, and Atlan can represent both structured features and LLM artefacts with consistent lineage. Tecton has added retrieval and embedding primitives. Feast has added vector-store integrations. Databricks Feature Store sits inside a broader MLflow-plus-Unity-Catalog story that covers both. The direction of travel is clear; the destination is not fully there yet.
What to decide now
Three decisions are worth making explicitly rather than drifting into.
- Do we still need a feature store for tabular ML? If you have tabular models in production with compliance, reuse, or point-in-time needs, yes, and more than ever. Do not let the LLM wave convince you otherwise.
- Where does embedding and retrieval artefact governance live? If the answer is "in our RAG framework" or "nowhere," you have a problem that will show up in an audit or a regression. Pick a home – inside your feature store if it supports it, otherwise in your ML metadata layer – and move the artefacts there.
- What is the catalogue of record? Feature stores work best when they are the authoritative source for a class of artefact and terrible when they overlap with a warehouse, a catalogue, and three pipeline tools. Pick your authoritative layer per artefact class and make the others subscribe.
The bottom line
Feature stores in 2026 are more useful than ever for the workloads they were designed for, and less sufficient than they used to be for the modern AI portfolio. The right posture is neither "we do not need a feature store in the LLM era" nor "our feature store will handle everything." It is a two-plane architecture with clear responsibilities, converged metadata, and a deliberate plan to bring LLM artefacts under the same governance discipline that tabular features earned over the last decade.
