A feature store expects a stream. Signals brings one.
Feature stores are built for teams who already have clean event infrastructure and a platform team to run it. Signals starts one layer earlier: collection, validation and the streaming engine come with it.
Same serving promise, different starting line.
| Dimension | Signals | Typical feature store |
|---|---|---|
| What you bring | An SDK in your app. Events are collected and schema-validated on the way in. | A working, modelled event stream. Building it is on you. |
| Who operates it | Managed. Windowing, late events and hot keys handled in the engine. | Usually your platform team, including the streaming jobs behind it. |
| Entity keys | Any entity: user, session, account, basket, listing, store. Identity resolution optional. | Supported, but the entity has to exist in your modelled data first. |
| Serving latency | 6ms p50, 10ms p95 in-region. One call returns a whole service. | Comparable online-store latency, once the online store is provisioned and warm. |
| Training and serving parity | One definition serves live and builds the training set, so the model trains on the value it will be served. | A core strength, assuming the offline source and the stream agree. |
| Training history | Computed on demand from the events you already have. Define an attribute today and train on your whole history today. | Point-in-time joins over values you computed and stored first. A new feature has no history until you backfill it. |
| Serving history | Turn on backfill and a new attribute is filled from your warehouse on publish. A returning customer is recognised on their first visit. | The online store starts empty until you materialise it from offline values you already have. |
| Who it is aimed at | Product and application engineers who want context in a render path. | ML platform teams serving models in production. |
| Time to first value | Days. Define one attribute, read it from your product. | Weeks to months, mostly spent upstream of the store itself. |
Based on published documentation for common open-source and managed feature stores · confirm against the vendor being evaluated
The event pipeline does not exist yet, or exists but nobody trusts it.
The consumer is an application surface, not only a model.
You need to key on things that are not users: baskets, listings, stores.
You do not want to staff a streaming platform team to get there.
The outcome you predict is something the customer does, and the inputs are behaviour.
You already run trusted streaming infrastructure and a team to maintain it.
Your primary consumers are training pipelines and model servers.
You need deep integration with a specific ML orchestration stack.
Feature lineage inside the ML lifecycle is the thing being bought.
Most of your model's inputs come from warehouse tables rather than behaviour.
Signals can be the stream your feature store was waiting for.
Signals upstream, feature store downstream
Collect and validate with Signals, land the stream, and let the feature store keep serving your models.
Signals for the application path only
Models keep reading the feature store; the storefront and service desk read Signals at request time.
Signals instead, for now
Teams without a platform team start on Signals and add a feature store later if the ML estate demands it.
p50 in-region read, one call per service
Streaming infrastructure your team runs
Shared by live serving and the training set
user · session · basket · listing · store
The questions your architect will ask.
Is this a feature store?
It overlaps on serving and on definition parity. It differs in bringing collection and validation with it, and in being aimed at application engineers as much as ML teams.
Can we keep the feature store we already run?
Yes. The common pattern is Signals for the application path and the existing store for model training and serving. Or build the training set with Signals from behaviour and keep the store for everything else.
What about point-in-time correctness?
The dataset builder computes each attribute from only the events before the moment you are predicting from, with the same definitions the live surface reads. Nothing that happened afterwards can leak into training.
What happens when serving is unreachable?
The SDK reports it and marks values stale. Your application decides whether to fall back or degrade the surface.
Test the claim on your own events.
Define one attribute, read it from your product, and compare the latency to whatever you run today. 14 days, no card, no sales call.
Also in Evaluate: Signals vs building it yourself, Signals vs a CDP, and pricing →