A feature store gives a team a place to find and use machine-learning features without guessing who owns them, how they were defined, who may access them, or which models depend on them. Think of it as a showroom for features, not necessarily a new warehouse for their data: it can sit on top of an existing data store. Its value is a governed, documented source of truth, not simply another way to query rows. section 3.4.4
That distinction matters when a feature moves from training to production. A value that is easy to calculate afterward in SQL—such as the average number of requests over the last 30 seconds—may be difficult to provide during live inference. Feature-store abstractions help reduce this training-serving skew. Point-in-time retrieval also lets a historical query use the value appropriate to its timestamp, rather than a later value. section 3.4.4 section 6.1.6
Keep the roles of adjacent tools distinct:
- A data store holds the underlying data; a feature store makes features discoverable and manageable over that data. section 3.4.4
- A vector database supports similarity search. A feature store can, where supported, sit over one to manage embeddings across data sources, model experiments, and updates. They need not be competing destinations. section 3.4.5
A question-and-answer feature view
In a Feast example, questions, answers, and question embeddings are saved to a local Parquet file. A feature view identifies the question ID as its entity, names the feature columns and file source, and sets a one-day time to live. After registration with `feast apply` and materialization, `get_online_features` retrieves those fields by question ID for inference. The local file is a demonstration backend; production use calls for an appropriate backend integration. The example also motivates timestamped queries with answers that change over time. section 6.1.6
Listing 6.5 Feast FeatureView definition
from feast import Entity, FeatureView, Field, FileSource, ValueType
from feast.types import Array, Float32, String
from datetime import timedelta
path = "./data/qa.parquet"
question = Entity(name="question_id", value_type=ValueType.STRING)
question_feature = Field(name="questions", dtype=String)
answer_feature = Field(name="answers", dtype=String)
embedding_feature = Field(name="embeddings", dtype=Array(Float32))
questions_view = FeatureView(
name="qa",
entities=[question],
ttl=timedelta(days=1),
schema=[question_feature, answer_feature, embedding_feature],
source=FileSource(
path=path,
event_timestamp_column="datetime",
created_timestamp_column="created",
timestamp_field="datetime",
),
tags={},
online=True,
)
The FeatureView definition shows how an entity, schema, timestamps, source, and time to live are declared together. section 6.1.6
Listing 6.6 Querying a feature view at inference
import pandas as pd
from feast import FeatureStore
store = FeatureStore(repo_path=".")
path = "./data/qa.parquet"
ids = pd.read_parquet(path, columns=["question_id"])
feature_vectors = store.get_online_features(
features=["qa:questions", "qa:answers", "qa:embeddings"],
entity_rows=[{"question_id": _id} for _id in ids.question_id.to_list()],
).to_df()
print(feature_vectors.head())
The inference listing shows an online feature request by entity ID. section 6.1.6
