What is a feature store and do you still need one for LLM apps?

A feature store is the data infrastructure that computes, stores, serves, and governs the features a machine learning model uses for prediction. It solves two specific problems: making the same feature available consistently for both training (offline, in batch) and inference (online, at low latency), and letting teams reuse and govern features instead of re-engineering them for every model.

For classic ML — fraud scoring, recommendations, churn, pricing — a feature store is often essential. For pure LLM apps built on retrieval-augmented generation (RAG), you usually do not need a traditional feature store; a vector database and embedding pipeline cover most needs.

But the moment your LLM system blends structured signals — user history, real-time context, personalization features — into prompts or tool calls, a feature store becomes valuable again.

What a feature store actually does

A feature store sits between your raw data and your models, and it does four jobs. First, it runs feature pipelines that transform raw data (events, tables, streams) into model-ready features. Second, it maintains an offline store — typically a data warehouse or lakehouse — that holds the full history of feature values for training and batch scoring.

Third, it maintains an online store — a low-latency key-value database like Redis, DynamoDB, or Cassandra — that serves the freshest feature values to live models in milliseconds. Fourth, it provides a registry so features are discoverable, documented, versioned, and reusable across teams.

The problem it was built to solve: training-serving skew

The original reason feature stores exist is training-serving skew. A data scientist computes a feature one way in a training notebook (say, a 30-day average purchase value from the warehouse) and an engineer reimplements it differently in the production service. The two computations diverge, the model sees different inputs in production than it trained on, and accuracy quietly collapses.

A feature store eliminates this by defining each feature once and serving the identical logic to both the offline and online paths. This single guarantee — consistency between training and serving — is the core value, and it has nothing to do with whether you are using an LLM or a gradient-boosted tree.

Reach Kory White, Fractional CRO: 📅 Book a Quick Call · 💼 Kory on LinkedIn · 🏢 CRO Syndicate

Where LLM apps differ

Most LLM applications are built on retrieval, not features. A RAG system chunks documents, embeds them, stores the vectors in a vector database (Pinecone, Weaviate, Qdrant, pgvector), and at query time embeds the user question and retrieves the nearest chunks. There are no engineered numeric features and no training-serving skew in the classic sense — the "feature" is unstructured text turned into an embedding.

For this pattern, a vector database plus an embedding pipeline is the right infrastructure, and a traditional feature store adds little.

So the honest answer for a pure document-Q&A chatbot is: no, you do not need a feature store. Pinecone or pgvector and a clean ingestion pipeline are enough.

When LLM apps DO benefit from a feature store

The picture changes when your LLM system is not just answering from documents but is personalized, contextual, or agentic. Consider these patterns:

• Personalized assistants that inject a user's structured profile — lifetime value, tier, recent behavior, entitlements — into the prompt or use it for routing. Those are exactly the consistent, governed, low-latency features a feature store serves best.
• Agentic systems and tool calls where the LLM decides to fetch a real-time signal (current account balance, inventory level, risk score). Serving those signals consistently and fast is feature-store territory.
• Hybrid ML + LLM pipelines where a classic model (a ranker, a classifier, a fraud score) runs alongside the LLM and shares features.

In these cases the feature store and the vector database coexist: the vector DB handles unstructured retrieval, and the feature store handles structured, real-time, governed signals that condition the model's behavior. Increasingly, the two converge — platforms like Tecton and Databricks now serve embeddings and vector features alongside traditional features, and Hopsworks offers a built-in vector index next to its feature store.

The real feature stores teams use

• Feast — the leading open-source feature store; lightweight, framework-agnostic, and a common starting point. You bring your own offline (BigQuery, Snowflake, Redshift) and online (Redis, DynamoDB) stores.
• Tecton — a managed, enterprise feature platform with strong real-time and streaming feature support, built by people from Uber's Michelangelo platform.
• Databricks Feature Store / Feature Engineering — native to the Databricks Lakehouse, with tight lineage to Unity Catalog and MLflow.
• Vertex AI Feature Store — Google Cloud's managed offering, integrated with BigQuery and Vertex pipelines.
• Amazon SageMaker Feature Store — AWS's managed offline/online store integrated with the SageMaker ecosystem.
• Hopsworks — an open-source-rooted platform that combines a feature store with a built-in vector index, explicitly bridging classic ML and RAG.

Decision guide

The practical rule: start simple. Ship your RAG app on a vector database. Introduce a feature store only when you find yourself injecting structured, real-time, or reusable signals into prompts and tool calls — at which point training-serving consistency, low-latency serving, and governance become real problems again, and the feature store earns its place.

Frequently Asked Questions

Is a vector database a kind of feature store? Not exactly, though they overlap. A vector database is optimized for similarity search over embeddings; a feature store is optimized for consistent offline/online serving of governed features. Some modern platforms (Hopsworks, Tecton, Databricks) blend both, and an embedding can be treated as a feature — but their core jobs differ.

Can I just store user features in Redis without a feature store? You can, and many teams do at first. The downside is you reimplement feature computation for training versus serving (reintroducing skew), and you lose discoverability, versioning, and governance. A feature store formalizes what ad hoc Redis usage does informally, which matters as the number of features and models grows.

Does RAG cause training-serving skew? Not in the classic sense, because there is no model retraining loop on engineered features. The closest analogue is embedding consistency — you must embed documents and queries with the same model and version, or retrieval quality degrades.

That is an embedding-pipeline concern, handled by versioning your embedding model, not by a feature store.

What is the difference between online and offline stores? The offline store holds full historical feature values for training and batch scoring (usually a warehouse or lakehouse). The online store holds only the latest values, optimized for millisecond reads during live inference (usually Redis, DynamoDB, or Cassandra).

A feature store keeps them in sync from one feature definition.

Do agents need a feature store? Agentic LLM systems that call tools to fetch real-time structured signals benefit from one, because those signals must be served fast, consistently, and with governance. If your agent only retrieves documents, a vector database is sufficient.

Is Feast enough for production? Feast is production-proven for many teams, especially those comfortable wiring up their own offline and online stores. Teams needing heavy real-time/streaming features, managed operations, or enterprise governance often move to Tecton, Databricks, or a cloud-native store.

Sources

• Feast documentation — https://docs.feast.dev/
• Tecton documentation — https://docs.tecton.ai/
• Databricks Feature Engineering — https://docs.databricks.com/machine-learning/feature-store/
• Vertex AI Feature Store — https://cloud.google.com/vertex-ai/docs/featurestore
• Amazon SageMaker Feature Store — https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html
• Hopsworks documentation — https://docs.hopsworks.ai/
• Google "Rules of Machine Learning" (training-serving skew) — https://developers.google.com/machine-learning/guides/rules-of-ml