A fraud model is only as current as its features. Snowflake's Online Feature Store is now generally available

Consider two versions of the same card fraud check.

In the first, the model scores a transaction using features computed last night: the customer’s average spend, usual merchants, usual countries. A card stolen this morning and used six times in an hour looks normal, because the features describe yesterday’s customer.

In the second, the same model reads features updated from the event stream: transactions in the last ten minutes, a new device, a merchant category never seen before. The model is identical. The decision is not.

That difference, between a model that is good and a model that is current, is what Snowflake moved to general availability on October 20.

What became GA

Online Feature Store serves the latest feature values with low-latency retrieval for real-time machine learning: fraud detection, recommendations, personalization. It supports batch, stream and real-time feature views, takes events through REST APIs, and integrates with real-time model inference. Teams choose a size for the online service and can resize it as traffic changes. Feature Store monitoring in Snowsight is also GA, tracking offline refresh status, online serving latency and errors, and stream ingestion health.

Two constraints: it is available in AWS and Azure commercial regions, not on Google Cloud, and billing has three parts (online service compute, autoscale compute and storage), so the cost of serving features is separate from the cost of the warehouse.

Before and after

Before an online store, most enterprises had two feature paths: a governed offline one, in the warehouse, used for training; and an operational one, built by an application team in a cache or key-value store, used for serving. The two drifted. A feature computed one way in training and another way in production is one of the most common reasons a model that tested well underperforms after launch.

With the online store inside the same platform as the training data, the definition of a feature can be written once and served in both places. That does not guarantee consistency, but it removes the most common reason for its absence: two teams writing the same logic twice.

The same applies to AI agents and decision models that act on live context. Snowflake’s own typed decision models are fast; their decisions are only as good as the inputs they are given at that moment. And as we noted on the agent data path, latency problems in AI systems often sit in data retrieval rather than in the model.

What to add when adopting it

A freshness objective per feature. “Low latency” describes how fast a value is read, not how old it is. For each feature used in a real-time decision, define how stale it may be, and alert on it. The monitoring that is now GA gives the signals; the thresholds are a business decision.

A fallback rule. When the stream stalls, should the model score with stale features, use a default, or route the case to review? Each answer has a different risk. Decide it before the first incident.

A check that training and serving match. Periodically compare served feature values with the values the offline pipeline computes for the same entities and time. Drift between them is a defect, even when both paths come from the same platform.

A cost owner. Online serving runs continuously. Its compute and autoscaling should be in a budget with a named owner, like any other production service.

Fresh features do not make predictions correct. They make sure a correct model is looking at the present.