A feature store is a centralized system for storing, serving and reusing the engineered features that feed machine learning models, solving the problem of training-serving skew where the feature logic used during training does not exactly match what runs in production. It typically has an offline store for historical feature values used in training, an online store optimized for low-latency lookups during inference, and a registry that lets a team reuse a feature another team already built rather than recomputing the same logic. Whether a company needs one depends on how many models share the same features and how strict the latency requirements are; a single team running one or two batch models can usually get by with well-organized SQL or dbt transformations, while an organization running many real-time models across teams benefits from a shared feature store like Feast, Tecton or a cloud-native equivalent. The clearest signal a feature store is worth the investment is duplicated feature logic across teams or bugs caused by training and serving pipelines drifting apart. For most LLM-centric applications relying on retrieval rather than structured features, a feature store is unnecessary. Nanobase AI evaluates actual feature reuse and latency needs before recommending one instead of adding infrastructure a team will not fully use.
Offline and online stores solve two different engineering problems
A feature store is really two systems wearing one name, and conflating them causes most "do we need one" confusion. The offline store holds historical feature values used to train a model, optimized for scanning large volumes of data over long time ranges. The online store holds the current value of each feature, optimized for single-record lookups in single-digit milliseconds, because a fraud-scoring model at inference time cannot wait on a batch query. Guaranteeing the inference-time value matches what training computed for the same entity is the actual hard problem it solves.
| Requirement | Offline store | Online store |
|---|---|---|
| Latency | Seconds to minutes (batch scan) | Single-digit milliseconds |
| Data volume | Full history, all entities | Current value per entity only |
| Consistency need | Point-in-time correctness for training | Freshness at request time |
| Typical backend | Data warehouse, lakehouse, Parquet | Redis, DynamoDB, key-value store |
A feature store is the plumbing that keeps these two stores in sync, not a new place to compute features from scratch.
A decision checklist before adopting one
- Count how many production models read the same underlying feature, computed by more than one pipeline. One is normal duplication; three or more is the real signal.
- Check whether any model needs a feature refreshed in under a second during inference; that alone often justifies an online store regardless of team size.
- Ask whether two teams have already shipped a bug caused by a mismatch between training-time and production feature values.
- Estimate the operational cost of running and securing an additional stateful service someone has to patch and monitor indefinitely.
- Confirm the models in question consume structured, tabular features rather than unstructured text passed to a retrieval system.
If fewer than two of these apply, well-organized SQL or dbt transformations are very likely a better use of engineering time than standing up Feast or Tecton.
Why a vector index is not a feature store
Teams building RAG systems sometimes ask whether their vector database needs a feature store on top, and the answer is almost always no. A vector index stores embeddings for similarity search: given a query, find semantically similar passages. A feature store stores structured values, such as a customer's 30-day transaction count, for a model that scores that customer directly. An application that only retrieves and generates text, with no structured scoring model in the loop, has no features to store.
Confusing retrieval infrastructure with feature infrastructure leads teams to buy tooling that solves a problem they do not actually have.
What most teams run instead
A single team with one or two batch-scored models rarely needs dedicated feature-store software. Well-tested SQL views or dbt models, computed on a schedule and written to a table both training and serving read from, cover the consistency problem well enough at that scale. The gap appears once a second team wants to reuse the first team's feature without copying its SQL, or a model needs a fresher value than the last batch run allowed.
When the investment pays for itself
A dedicated feature store like Feast, Tecton or a cloud-native equivalent earns its keep once an organization runs enough real-time models, across enough teams, that reuse and point-in-time correctness become a shared platform concern rather than one team's SQL discipline. At that stage the registry, letting a team discover a feature another team already validated, often saves more time than the online store itself.
Frequently asked questions
Does a RAG or LLM application need a feature store?
Rarely. A RAG pipeline retrieves text passages by similarity, which a vector index handles; there is usually no structured feature being served to a scoring model. A feature store becomes relevant only if the same application also runs a traditional model, such as risk scoring, on structured signals.
What is the difference between Feast and Tecton?
Feast is open source and self-hosted, giving full control at the cost of running and upgrading it yourself. Tecton is a managed commercial platform built by some of Feast's original authors, trading that operational burden for a subscription, which suits teams that want the pattern without a dedicated platform team.
Can we start without a feature store and add one later?
Yes, and this is the more common path. Most teams start with SQL or dbt-based features, add a lightweight registry once duplication appears, and adopt a full feature store only once real-time serving or cross-team reuse makes the cost worthwhile.
How long does adopting a feature store typically take?
Migrating existing features and wiring both pipelines to read from the new store typically takes a few weeks each, not counting every legacy feature; most teams migrate incrementally rather than in one cutover.
How Nanobase AI helps
Nanobase AI reviews which features are actually duplicated across a client's models and how strict the real latency requirements are before recommending new infrastructure, since a feature store added without that reuse is a cost with no offsetting benefit. Where one genuinely fits, we set it up alongside the broader MLOps stack already in place. For RAG-heavy applications, we instead build a document pipeline that keeps freshness and access control intact without conflating retrieval and feature infrastructure.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.