Feast gives you the framework. Signals runs it for you.
Feast is open source and free to adopt, which is not the same as cheap to operate. The online store, the streaming jobs, the registry and the on-call rotation are yours. Signals is the managed version of that problem, with collection included.
Free to adopt, yours to operate.
| Dimension | Signals | Feast |
|---|---|---|
| What it is | A managed service. Collection, computation, serving and triggers in one product. | An open-source framework and registry. You assemble the infrastructure it sits on. |
| What you bring | An SDK in your app. Events are collected and schema-validated on the way in. | A working event stream, an online store, an offline store and the jobs that connect them. |
| Who operates it | Managed. Windowing, late events and hot keys are handled in the engine. | Your platform team, including the online store and every streaming job behind it. |
| Attribute update latency | <1s from the event to the attribute being current. | Whatever your streaming ingestion achieves. The online store is only as fresh as the job writing to it. |
| Serving latency | 6ms p50, 10ms p95 in-region. One call returns a whole service. | Depends entirely on the online store you chose and how you sized it. |
| Schema and validation | Events are validated against a schema at collection, so a bad event is caught before it reaches an attribute. | Out of scope. Feature definitions assume the upstream data is already correct. |
| Who defines an attribute | A product manager in the console, or an engineer in code through CI/CD. | An engineer, in Python, followed by a deployment of the jobs behind it. |
| Real-time triggers | Conditions evaluated continuously, delivered to your app or to Braze, Kafka, webhooks and Pub/Sub. | Not in scope. Triggers are a second system you build beside it. |
| Cost shape | Metered on events processed and attribute reads. No infrastructure to size. | No license cost, plus the infrastructure bill and the engineers who keep it running. |
Based on the open-source project's published documentation at the time of writing · confirm against the version and deployment you are evaluating
You do not want to staff a platform team to keep a serving layer alive.
The behavioral events do not exist yet, or exist and nobody trusts them.
The consumer is an application surface or an agent, not only a model.
You want triggers on live conditions without building a second system for them.
Year two ownership cost is the number your buyer is actually asking about.
You already run the streaming and storage infrastructure, and a team that maintains it.
Open source with no vendor relationship is a hard requirement.
You need to sit on a specific online store you have already standardized on.
Your inputs come mostly from warehouse tables rather than live behavior.
The feature registry itself, rather than the serving, is what you are adopting.
Signals can be the stream Feast was waiting for.
Signals upstream, Feast downstream
Collect and validate behavior with Signals, land the stream, and let Feast keep serving your models from it.
Signals for the application path only
Models keep reading Feast. The product surfaces and agents read Signals at request time, where the render budget is tight.
Signals instead of the operational half
Keep the feature definitions you already wrote, and stop operating the online store and the jobs that fill it.
p50 in-region read, one call per service
Streaming infrastructure your team runs
Event in to attribute current
user · session · basket · listing · store
The questions your architect will ask.
Feast is free. Why would we pay for this?
The license is free and the operation is not. Price the online store, the streaming jobs, the registry upkeep, the upgrades and the on-call rotation, then compare. If your platform team already exists and has capacity, Feast may well be the right answer.
Can we keep the feature definitions we already wrote?
The definitions do not port across directly, but the thinking does. The Signals equivalent is shorter, because windowing and late-event handling sit in the engine rather than in a job you wrote.
Does Signals replace our online store?
For the attributes it computes, yes. Teams commonly keep an existing store for warehouse-derived features and use Signals for the behavioral, in-session half.
What happens when serving is unreachable?
The SDK reports it and marks values stale, and your application decides whether to fall back or degrade the surface. On a store you host, the same question is yours to answer, along with the paging that comes with it.
Price year two, not the proof of concept.
Define one attribute against your own traffic, read it from your product, and compare what it took to get there.