Feature Stores Explained (2026): Online vs Offline, Feast, Tecton, LLMs

Every few months someone asks me whether they should "add a feature store" to their ML stack, usually in the same tone they would use for adding a cache: a box you drop in and things get faster. A feature store is not that. It is a contract between the people who build training data and the service that answers a prediction request in 20 milliseconds, and the contract is mostly about time. This post explains what a feature store actually does in 2026, why it has two databases, what point-in-time correctness and training/serving skew mean in practice, where Feast, Tecton, Hopsworks, Databricks, Vertex and SageMaker stand after a busy year, and whether an LLM app or AI agent needs one at all.

What is a feature store, in plain terms?

A feature is an input to a model, computed from raw data: "number of transactions this customer made in the last 7 days", "average basket size", "minutes since last login". A feature store is the system that defines those features once, computes or ingests them, stores their history, and serves them two ways: in bulk for training and with low latency for live inference.

The idea came out of large in-house platforms. Uber says it launched Michelangelo in early 2016 to standardise ML workflows, and that its feature store, Palette, now hosts more than 20,000 features shared across teams. Tecton was later founded by people who built that platform, which is why the Databricks announcement still cites that lineage.

Strip away the vendor diagrams and a feature store has four parts:

1. A registry: the catalogue of entities (customer, driver, merchant), feature definitions, owners and versions. In Feast this is a file or a SQL database.
2. An offline store: the full history of feature values, usually in your warehouse or lake (BigQuery, Snowflake, Redshift, Delta, Parquet on S3).
3. An online store: only the latest value per entity, in something fast for key lookups (Redis, DynamoDB, Bigtable, Postgres).
4. A serving and materialisation layer: jobs that copy fresh values from offline to online, plus an API that returns a feature vector for a list of entity keys.

Online store vs offline store: why are there two databases?

Because the two consumers want opposite things. Training wants millions of rows, every historical value, joined against labels, and does not care if the query takes four minutes. Inference wants one row per entity, the newest value only, in single-digit milliseconds, thousands of times a second. No single database is good at both at a sane price, so feature stores split the workload.

Concern	Offline store	Online store
What it holds	Full history of every feature value	Latest value per entity key
Typical backends	BigQuery, Snowflake, Redshift, Spark/Delta, Parquet (Feast offline stores)	Redis, DynamoDB, Bigtable, Postgres (Feast Redis store)
Query shape	Large point-in-time joins	Key lookups for a handful of entities
Latency target	Seconds to minutes	Milliseconds
Who reads it	Training jobs, batch scoring, backfills	Model servers, APIs, agents
How it is filled	Your pipelines write to it	Materialisation from offline, or push/stream writes

The step between them is called materialisation. In Feast it is feast materialize-incremental <end_date>, which reads the offline store for the window since the last run and upserts the newest values per key into the online store. The details of how the online store lays out data matter more than people expect: Feast's Redis store keeps all feature views for the same entity in one Redis hash, so a request that spans several feature views is a single pipelined round trip. Its Postgres store stores only the latest feature values and, as of 0.67, batches reads across feature views into one query.

What is point-in-time correctness, and why does it matter?

This is the part that earns a feature store its keep. When you build a training set, each label happened at a specific moment: the transaction was flagged as fraud at 12:00 on 20 October. The features for that row must be the values that were known at 12:00 on 20 October, not the values in the table today. If you join on customer ID alone, you quietly hand the model information from the future. It looks brilliant offline and then underperforms in production, because production never sees the future.

Feast's point-in-time join handles this by taking an entity dataframe (keys plus timestamps) and, for each row, looking backward for the most recent feature value within the feature view's TTL. TTL is measured from each row's timestamp, not from when you run the query. There is also a filter_by_created_timestamp option that keeps late backfilled values out of training data.

I ran this on Feast 0.67.0 with a toy table of daily customer stats. The customer had txn_count_7d = 18 on 20 October and 28 on 21 October. Asking for features as of 20 October 12:00 returned 18, which is correct. A naive "latest value" join would have returned whichever row was newest. Here is the core of it:

# feast==0.67.0, Python 3.12
from datetime import datetime, timezone
import pandas as pd
from feast import FeatureStore

store = FeatureStore(repo_path="feature_repo")

# One row per label: the key, WHEN the label was observed, and the label.
entity_df = pd.DataFrame({
    "customer_id": [1001],
    "event_timestamp": [datetime(2026, 10, 20, 12, 0, tzinfo=timezone.utc)],
    "is_fraud": [0],
})

training_df = store.get_historical_features(
    entity_df=entity_df,
    features=["customer_stats:txn_count_7d", "customer_stats:avg_amount_7d"],
).to_df()
# txn_count_7d == 18: the 20 Oct value, not the 21 Oct value (28)

You can write this join yourself in SQL with a window function, and plenty of teams do. The value of the feature store is that nobody has to remember to, for every feature, forever. The step-by-step version of this, with Redis and Postgres, is in my Feast setup guide.

What is training/serving skew?

Google's Rules of ML defines it bluntly: training-serving skew is a difference between performance during training and performance during serving. The usual causes are boring:

• Two implementations of the same feature. A data scientist computes "7-day average" in a pandas notebook, a backend engineer reimplements it in Go for the API, and the two disagree on time zones or whether "7 days" includes today. Rule #32 in that guide is literally "reuse code between your training pipeline and your serving pipeline".
• Joining against a table that changes. Rule #31 warns that if you join with a table at training time and it changes, the same example gets different feature values in training and serving.
• Freshness mismatch. Training used hourly values; production reads a value that was materialised yesterday because the job failed quietly.

A feature store addresses the first two by making one definition the source of truth for both paths. It addresses the third only if you monitor materialisation like any other production pipeline, which is where ordinary platform discipline comes in. Alert on job failures and on feature age, and treat a stale online store as an incident, the same way you would treat a stale cache that serves money. Rule #29 offers a cheaper alternative worth knowing: log the features you actually served and train on those logs. Feast supports this through feature service logging, and for some teams it is all they need.

Feast, Tecton, Hopsworks, Databricks, Vertex and SageMaker in 2026

The market moved a lot in the past 14 months. The biggest change: Databricks announced on 22 August 2025 that Tecton would join Databricks, pitching Tecton's real-time serving (it quotes sub-10 ms latency and sub-100 ms freshness) as a data layer for Agent Bricks. The post does not disclose terms, and I have not found an official end-of-life or migration plan for standalone Tecton customers, so if you run Tecton today, ask your account team directly and get the answer in writing.

Option	Status in late 2026	Online store	Fits best when	Source
Feast	Open source, Apache-2.0, v0.67.0 released 13 Oct 2026	Redis, Postgres, DynamoDB, Bigtable, SQLite and more	You want a thin, self-hosted layer over your existing warehouse	GitHub release
Tecton	Joining Databricks (announced Aug 2025)	Managed	Real-time fraud, risk and personalisation at scale	Databricks blog
Databricks Feature Engineering	Online stores created after 23 Mar 2026 use Lakebase Autoscaling	Lakebase (managed Postgres)	You already live in Unity Catalog	Databricks docs
Hopsworks	4.7 GA, 31 Jan 2026	RonDB	You want a full self-hostable platform with on-demand transforms	Hopsworks 4.7
Vertex AI Feature Store	BigQuery offline; Optimized serving frozen from 17 May 2026, removed 17 Feb 2027	Bigtable serving	You are all-in on BigQuery	Google docs
SageMaker Feature Store	Standard and InMemory (ElastiCache-backed) online tiers	Managed	You are all-in on AWS and SageMaker	AWS docs

A few notes that do not fit in a table. Feast is a library and a CLI more than a platform: it does not run your transformation pipelines for you in the way Tecton did, and its own docs recommend running feast plan in CI on pull requests and feast apply on merge (running Feast in production). The 0.67 release added a standalone MCP server, a Trino compute engine, Lance data sources and version pinning for feature services, so it is moving fast. On Google Cloud, if you still use Optimized online serving, you have a migration due before February 2027; Bigtable serving supports scheduled and continuous sync but does not do embeddings management. Google also folded Vertex AI into Gemini Enterprise Agent Platform in April 2026, so expect renamed console pages. I covered that broader platform shuffle in MLOps platforms compared.

Do you actually need a feature store?

My honest default for most teams is no, not yet. You need one when at least two of these are true:

• You serve predictions online and the features depend on recent behaviour (fraud, risk, ranking, recommendations, dynamic pricing). Batch-scored models that write results to a table rarely need an online store.
• More than one model or team reuses the same features, and you are already seeing three slightly different definitions of "active user".
• You have been bitten by leakage or skew at least once, which usually shows up as a model that was great in the notebook and mediocre in production.
• Freshness is a requirement, measured in minutes or seconds, not days.

If you have one batch model and one data scientist, a well-tested SQL view with a window function and a logged prediction table will serve you better. If you are on Databricks or Vertex already, start with the built-in option before adding Feast, because the cheapest feature store is the one that is already in your bill and your IAM model. If you are multi-cloud or self-hosted, Feast with Redis or Postgres is a reasonable, boring choice.

Do LLM apps and AI agents need a feature store?

Mostly they need retrieval, not features. A RAG chatbot over documents needs chunking, embeddings and a vector index, and for most teams pgvector is enough. Bolting a feature store onto that adds a registry and a materialisation job for no gain.

The case changes when the LLM or agent needs structured, per-entity, fresh facts in its context: a support agent that should know this customer's plan, open tickets and failed payments from the last hour; a fraud copilot that reads the same risk signals the scoring model uses. That is exactly the "latest value for this key, fast, consistently defined" problem a feature store solves, and it is why Databricks framed Tecton around agents. Feast has an experimental vector database API and now ships an MCP server, so an agent can fetch features as a tool call. The discipline that matters is the same as for any agent tool: scoped access, audit logs, and no direct write path. If an agent can read features, decide whether it should ever see raw PII features at all.

FAQ

What is the difference between a feature store and a data warehouse?

A warehouse stores data; a feature store stores feature definitions plus their history and latest values, and adds point-in-time joins and low-latency serving. Most feature stores use your warehouse as the offline store. The feature store is the layer that makes the same definition usable for training and serving.

Is Feast still maintained in 2026?

Yes. Feast is Apache-2.0, released v0.67.0 on 13 October 2026, and ships roughly monthly. It is a lighter tool than managed platforms: it handles definitions, point-in-time retrieval, materialisation and serving, but you bring your own pipelines and scheduler.

What happened to Tecton?

Databricks announced on 22 August 2025 that Tecton would join Databricks, with plans to fold its real-time serving into the Databricks platform and Agent Bricks. Terms were not disclosed in the announcement. Existing customers should confirm support and roadmap directly with Databricks.

Do I need a feature store for RAG?

Usually not. RAG needs a vector index and a document pipeline. A feature store becomes useful when your LLM app also needs fresh, structured, per-user or per-entity facts that must match what your other models see.

This quarter, if I owned an ML platform with online models, I would do three things: write down every feature that is computed in more than one place, add a point-in-time test like the one above to CI, and put an alert on materialisation age before buying anything. If that inventory is long, Feast on Redis or the built-in store on the platform you already pay for is the next step, and the setup guide gets you there in an afternoon. If the list is short, a tested SQL view is still a perfectly respectable feature store.

Related: MLOps vs LLMOps vs AgentOps in 2026: What Carries Over, What's New, Vector Databases in 2026: Do You Need One, or Is pgvector Enough? and MLOps Platforms Compared 2026: MLflow vs Kubeflow vs SageMaker vs Vertex.