AI on Google Cloud<\/a>, Feature Store is the bridge between data engineering and online ML serving. It exists to keep training and serving features consistent, versioned, discoverable, and retrievable at the latency an online model requires.<\/p>\nThe most important 2026 change is that Optimized online serving is deprecated; Google directs new designs toward Bigtable online serving for tabular features and Vector Search for embeddings.<\/p>\n
BigQuery is the current offline feature store<\/h3>\n Feature data is stored in BigQuery tables or views, where columns represent features and rows represent entity records.<\/p>\n
This removes the need to import the same historical dataset into a separate Vertex-managed offline store.<\/p>\n
Training and batch prediction can query BigQuery directly, while Feature Store resources add metadata and online-serving capabilities.<\/p>\n
Entity IDs and feature timestamps define the data model<\/h3>\n Each feature record needs one or more entity ID columns so online serving can fetch the correct entity.<\/p>\n
For time-series feature data, include a feature timestamp to indicate when values were generated.<\/p>\n
Point-in-time correctness during training depends on retrieving features as they existed at the prediction time rather than leaking later values into historical examples.<\/p>\n
Feature Registry is optional but valuable for governance<\/h3>\n Teams can serve directly from a BigQuery source without registering feature groups\/features, provided every row has a unique entity ID under the documented constraints.<\/p>\n
Registering feature groups and individual features becomes useful when data contains multiple records per entity, when features come from several sources, or when monitoring and metadata discovery matter.<\/p>\n
Use the registry for shared production features, not for every transient notebook column.<\/p>\n
Feature groups map BigQuery sources into managed metadata<\/h3>\n A feature group references a BigQuery table or view and defines entity ID columns plus a feature timestamp when applicable.<\/p>\n
Individual Feature resources then reference specific columns.<\/p>\n
Current Feature Store can use dedicated service accounts for feature groups, helping restrict a feature group’s access to only the BigQuery source it needs.<\/p>\n
Feature views define what the online store serves<\/h3>\n A FeatureView can be associated with registered features from one or more feature groups or directly with a BigQuery source.<\/p>\n
It represents the logical set of fields materialized into an online-serving instance.<\/p>\n
Keep views aligned with model\/service needs so low-latency serving does not copy dozens of unused columns simply because they exist in the warehouse.<\/p>\n
Bigtable online serving is the current strategic path<\/h3>\n Google documents Bigtable online serving as appropriate for large feature volumes with high durability and support for scheduled or continuous sync.<\/p>\n
It does not support embedding management; Google recommends purpose-built Vector Search for embedding use cases.<\/p>\n
Use Bigtable when the online model needs fresh tabular feature values keyed by entity ID at production scale.<\/p>\n
Optimized online serving is deprecated<\/h3>\n Google deprecated Optimized online serving on February 17, 2026, stopped new feature development after May 17, 2026, and currently plans full sunset on February 17, 2027.<\/p>\n
Existing users should migrate to Bigtable online serving for features and Vector Search for embeddings.<\/p>\n
Do not build new production dependencies around Optimized serving merely because old tutorials or examples still reference it.<\/p>\n
Continuous sync matters for rapidly changing features<\/h3>\n Bigtable online serving supports continuous data synchronization from BigQuery-backed feature views in addition to scheduled sync.<\/p>\n
This is useful for features such as recent user activity, device state, or account risk that become stale quickly.<\/p>\n
Define a freshness SLO and monitor sync lag; \u201conline store healthy\u201d does not mean the value is current enough for the model.<\/p>\n
Direct feature-view writes are a current preview path<\/h3>\n For Bigtable online stores, Google now offers a preview feature for directly updating feature values in a feature view without first writing BigQuery, enabling sub-second freshness targets.<\/p>\n
Those writes do not automatically update the BigQuery source, so the next sync can reconcile based on timestamps.<\/p>\n
Use this carefully: dual write paths require clear source-of-truth and reconciliation semantics.<\/p>\n
Feature monitoring should catch drift before serving quality degrades<\/h3>\n Feature Registry can support statistics and anomaly\/drift monitoring for registered features.<\/p>\n
Monitor distribution shifts, missing\/null rate, freshness, entity coverage, and schema changes alongside model performance.<\/p>\n
Drift alerts should route to a data owner because the root cause may be an upstream pipeline change rather than the model itself.<\/p>\n
Vertex AI Feature Store succeeds when training and serving use the same governed feature definitions<\/h3>\n The mature platform keeps historical features in BigQuery, uses point-in-time retrieval for training, registers shared features, serves low-latency values through Bigtable-backed feature views, monitors freshness\/drift, and has an explicit migration away from deprecated Optimized serving.<\/p>\n
Feature Store should reduce training-serving skew without creating a second uncontrolled copy of enterprise feature data.<\/p>\n
Feature ownership should be explicit. Every registered feature or feature group should have an owning team, business definition, source table, freshness expectation, and allowed use. A feature named `customer_value` is dangerous when different teams mean different windows or currencies. Metadata is part of feature reuse, not decoration.<\/p>\n
Point-in-time training queries should be treated as regression-tested code. Use BigQuery point-in-time functions or equivalent SQL patterns to ensure each training row only sees feature values available at that prediction timestamp. Add synthetic cases where future values would change the label so leakage tests can prove the join logic is correct.<\/p>\n
Entity-key design deserves careful review. Composite IDs can represent tenant plus customer or merchant plus account, but inconsistent formatting can create duplicate logical entities or failed lookups. Normalize key types\/format in BigQuery before serving and keep the same key construction in training and online request code.<\/p>\n
Online serving should have a fallback strategy. If Feature Store or Bigtable is temporarily unavailable, decide whether prediction should fail, use a safe default feature set, or route to a degraded model. Do not silently mix stale cached features with live features unless the model was evaluated for that behavior.<\/p>\n
Feature freshness should be monitored end to end: source event time, BigQuery load time, feature-view sync time, and online read time. This distinguishes an upstream data pipeline delay from an online-store sync issue. Service health without feature-age metrics can hide stale predictions for hours.<\/p>\n
Feature reuse should not create accidental coupling. A shared feature can be used by many models, so changing its definition or source may affect several production systems. Prefer creating a new version\/feature name for semantic changes and deprecate the old feature after downstream models migrate.<\/p>\n
Bigtable online serving and Vector Search should be treated as separate optimized stores. Tabular\/entity features fit Bigtable; embeddings and nearest-neighbor retrieval fit Vector Search. Avoid forcing embeddings into deprecated Optimized Feature Store merely to keep everything under one product name.<\/p>\n
Direct feature-view writes need reconciliation monitoring if adopted. Because a direct write does not update the BigQuery source, the platform should track which values exist only online and ensure a later source update\/sync does not unexpectedly overwrite a fresher value. Use event timestamps and a single ownership model for resolving conflicts.<\/p>\n
Feature registry metadata should distinguish raw source columns from engineered business features. A reusable feature such as `txn_count_7d` should document the aggregation window, timezone, inclusion rules, and null\/default semantics. Reuse only works when consumers can understand the exact transformation without reading the pipeline implementation.<\/p>\n
Feature updates should be idempotent and event-time aware. Streaming pipelines may deliver late or duplicate source events, and a simple latest-arrival write can overwrite a newer feature with older data. Use feature timestamps and source sequencing so online state reflects the newest business event, not merely the most recent network arrival.<\/p>\n
Model deployments should declare which feature view\/version they depend on. If a view changes fields or meaning, platform automation can identify impacted endpoints before rollout. Treat the feature view as part of the model serving contract, not as an invisible shared table that may change underneath multiple models.<\/p>\n
Feature Store incidents should have a data-quality fallback. A model can remain technically online while one important feature is null or stale for most entities. Monitor feature coverage and freshness at prediction time, and define whether the application rejects predictions, uses trained defaults, or routes to a fallback model when critical features are missing.<\/p>\n
Feature Store service accounts should be scoped to only the BigQuery datasets each feature group\/view requires. Dedicated service accounts are especially useful when domains should not share broad read access. Audit both the Feature Store IAM and underlying BigQuery permissions because online-serving security depends on both layers.<\/p>\n
Feature deprecation should be explicit. Mark replacement features, notify dependent model owners, keep old definitions stable during migration, and remove them only after no serving\/training workflow references them. Reuse is valuable only when shared features have a lifecycle that prevents semantic changes from breaking several models at once.<\/p>\n","protected":false},"excerpt":{"rendered":"
Vertex AI Feature Store’s current architecture is built around feature data in BigQuery. Instead of maintaining a separate offline store inside Vertex AI, teams keep recent and historical feature values in BigQuery tables or views, optionally register them in the Feature Registry, and configure online stores plus feature views for low-latency serving. Current Google documentation […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19931","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t