For years, machine learning teams have lived with a painful split: rich offline feature engineering in the warehouse for training, and a completely separate low-latency system for serving those same features at inference time. The gap creates training-serving skew, extra infrastructure, fragile sync jobs, and operational toil. Real-time use cases—fraud detection, personalized recommendations, dynamic pricing, next-best-action systems—demand features in milliseconds, not the seconds or minutes typical of warehouse queries.
On October 20, 2026, Snowflake made the Online Feature Store generally available. Built on a managed Snowflake Postgres serving layer, it delivers the latest feature values with ultra-low-latency online retrieval—typically under 10 ms at P50—while staying fully integrated with the offline Feature Store used for training. Teams can now use the same feature definitions for both worlds, ingest events via REST APIs, support batch, stream, and real-time feature views, and serve production traffic with elastic sizing and built-in monitoring.
This post examines the offline-to-online gap, the architecture of the GA Online Feature Store, its core capabilities, performance benchmarks, ideal use cases, implications for ML engineers, and what the release signals for production machine learning in the AI Data Cloud.
The Offline-to-Online Feature Gap
Offline feature stores excel at large-scale transformations, historical point-in-time correctness, and generating training datasets. They struggle when an application needs the current value of a user’s risk score, recent transaction velocity, or session embedding in under 20 milliseconds.
Common workarounds have included:
- Custom Redis or DynamoDB caches fed by streaming pipelines
- Separate online stores with dual-write or scheduled sync logic
- Hybrid tables or warehouse queries that cannot meet strict latency SLAs
- Feature stores from other platforms that still require data movement out of the primary lakehouse
Each approach introduces complexity, potential consistency issues, additional cost, and another system for MLOps teams to operate. Training-serving skew becomes a constant risk: the features a model sees in production may differ from those it was trained on.
Snowflake’s Online Feature Store closes this gap by keeping feature computation and training in the familiar Snowflake environment while providing a purpose-built, low-latency serving layer that stays automatically synchronized.
Architecture: Snowflake Postgres as the Serving Layer
The Online Feature Store uses a managed Postgres serving layer for point lookups. Feature values are keyed by entity (user ID, account ID, device ID, etc.) so applications retrieve the latest values in milliseconds instead of executing warehouse queries.
Key architectural elements include:
- Automatic synchronization from the offline store using a configurable target_lag (as low as 10 seconds).
- Stream feature views that ingest events in real time and update features with end-to-end freshness typically under 200 ms at P50.
- Real-time feature views that compute values at query time from request context and upstream features.
- A managed online service (created once per feature store schema) that exposes REST endpoints for both ingestion and retrieval.
- High availability and redundancy for sizes S and above.
- Seamless integration with the Snowflake Model Registry so deployed models can automatically fetch required online features at inference time.
Snowflake Postgres was chosen because it delivers production-grade latency, throughput, and operational characteristics while remaining part of the same security and governance perimeter as the rest of the AI Data Cloud. Internal production benchmarks against Databricks Online Feature Store (backed by Lakebase) showed 2.5× lower latency at equivalent throughput and 7× higher queries per second on comparable instances, with sustained 10 ms P50 at 1,500 QPS.
An alternative hybrid-table online serving path exists for simpler batch point-lookup workloads that do not require stream ingest, REST APIs, or the absolute lowest latency (hybrid tables typically achieve under 50 ms P50). For the most demanding real-time ML use cases, the Postgres-backed Online Feature Store is the recommended path.
Key Capabilities and Metrics
- Serving latency: Typically under 10 ms at P50 (REST query API)
- Stream freshness: End-to-end typically under 200 ms at P50
- Feature view types: Batch online, stream, and real-time
- Ingest & query: REST APIs with Programmatic Access Token (PAT) or key-pair authentication
- Sizing: XS (dev/test) through 3XL; resizable as traffic grows (GA)
- Availability: AWS and Azure commercial regions (not currently available on Google Cloud)
- Monitoring: Snowsight dashboards for offline refresh status, online serving latency/errors, and stream ingest health
- Integration: Automatic feature retrieval with Model Registry real-time services
Feature Views, REST APIs, and the Development Experience
Teams define features once using the familiar Feature Store Python API or the new declarative (snow feature CLI) plan-and-apply workflow.
- Batch online feature views serve the latest row per entity key, refreshed from the offline pipeline according to target_lag.
- Stream feature views accept events via the REST ingest API (or Python SDK) and maintain low-latency aggregates or latest values.
- Real-time feature views compute on the fly from the incoming request plus upstream online features.
Feature groups allow bundling multiple views into a single versioned unit for both training dataset generation and online retrieval, reducing the chance of training-serving mismatch.
At inference time, applications call the REST query endpoint with one or more entity keys and receive the corresponding feature vectors. When a model is deployed as a real-time service in the Model Registry, the platform can automatically resolve and inject the required online features, simplifying client code.
Monitoring, Observability, and Billing Model
Feature Store monitoring in Snowsight became generally available alongside the Online Feature Store. Operators can track:
- Offline feature view refresh health and lag
- Online serving latency percentiles and error rates
- Stream ingest throughput and health
Billing for the online service (effective around the GA timeframe) is based on three components:
- Online service compute — hourly rate determined by chosen size (XS–3XL). The service is always-on, so compute is billed continuously while the service exists.
- Autoscale compute — additional capacity when traffic exceeds the base size.
- Storage — monthly rate per terabyte of feature data stored in the online store.
This transparent, size-based model lets teams match cost to workload and resize as traffic patterns evolve. Development and testing can start on XS (non-HA); production workloads typically begin at S or M.
Ideal Use Cases
The Online Feature Store shines wherever decisions must be made in real time with fresh, entity-keyed features:
- Fraud and risk scoring — transaction velocity, device reputation, behavioral biometrics, and historical patterns returned in single-digit milliseconds so models can approve or decline before the user experiences latency.
- Personalization and recommendations — recent clicks, session embeddings, affinity scores, and inventory signals that update as the user interacts with the application.
- Dynamic pricing and offers — customer lifetime value proxies, price sensitivity indicators, and real-time demand signals.
- Next-best-action and customer support routing — context features that help agents or automated systems respond with the most relevant action.
- Any high-QPS inference path that previously required a separate online store or accepted higher latency.
Because the same feature definitions power both training and serving, teams reduce skew and accelerate the path from experimentation to production.
Performance Benchmarks vs. Alternatives
Public and internal benchmarks highlight the advantage of the Postgres-backed design:
- Typical P50 latency under 10 ms for point lookups.
- Sustained 10 ms P50 at 1,500 QPS in published comparisons.
- 2.5× lower latency and 7× higher QPS versus Databricks Online Feature Store on comparable infrastructure.
- Hybrid-table alternative delivers solid sub-50 ms performance for simpler needs without the full online service.
Actual results depend on feature width, number of keys per request, network distance, and payload size. Snowflake publishes a reproducible benchmark kit so customers can validate performance in their own environments.
Implications for ML Engineers and Platform Teams
The GA release meaningfully changes the daily experience of ML practitioners:
- One platform for feature engineering, training dataset generation, online serving, and model deployment.
- Elimination (or dramatic reduction) of dual-write pipelines and custom cache synchronization.
- Lower operational burden—Snowflake manages the Postgres instances, scaling, and high availability.
- Faster iteration: change a feature definition once and both offline and online paths update.
- Better governance: features remain under the same RBAC, masking, and audit controls as the rest of the data estate.
ML engineers can spend less time on infrastructure glue and more time on model quality and business impact. Platform teams gain a standardized, observable, and cost-transparent serving layer that scales with demand.
What This Signals for Production ML in the AI Data Cloud
The Online Feature Store GA is more than a point solution. It is a concrete step toward a fully integrated real-time ML stack inside the AI Data Cloud:
- Feature computation, storage, serving, model inference, and observability in one governed environment.
- Reduced data movement and simplified architectures.
- Support for the low-latency, high-freshness requirements of modern agentic and real-time AI applications.
- A clear path for teams that previously kept online features outside Snowflake to consolidate.
As organizations push more decisioning into real time, the ability to serve consistent, fresh features at millisecond latency without leaving the primary data platform becomes a competitive advantage. Combined with Model Registry real-time services, declarative feature workflows, and Snowsight monitoring, Snowflake now offers an end-to-end path from feature definition to production inference that few other platforms can match with the same degree of integration.
Actionable Insights for AI/ML Teams
- Inventory current real-time inference paths and measure existing feature-serving latency and operational cost.
- Identify 1–2 high-value use cases (fraud scoring or session personalization are common starting points) and pilot the Online Feature Store with a small set of entities and features.
- Start with an appropriate service size (S or M for most production pilots) and monitor latency and cost in Snowsight.
- Adopt feature groups early so training and serving stay aligned as the feature set evolves.
- Combine with Model Registry real-time services to minimize client-side feature fetching logic.
- Establish clear ownership for online service sizing, monitoring alerts, and cost reviews.
- Validate performance with the official benchmark kit under realistic key cardinality and feature width.
- Plan network access (including PrivateLink where required) early so REST endpoints are reachable from inference services.
The offline-to-online gap has long been one of the most friction-filled parts of production ML. With the Online Feature Store now generally available, Snowflake teams can close that gap with sub-10 ms latency, automatic synchronization, stream support, and a fully managed Postgres serving layer—while keeping everything inside the AI Data Cloud’s security and governance boundary. For organizations building real-time intelligent applications, that combination is transformative.