How the concepts map
| In Streams | In Data Feeds |
|---|---|
| A stream config (addresses, topics, ABIs) | A recipe plus SQL filters, e.g. token-transfers, contract-logs filtered to your addresses or topics |
| A webhook payload pushed per event | Rows in your own database, written by the sink as blocks land |
| Your webhook endpoint + retries + queue | Nothing: delivery, ordering, and resume are the sink’s job |
confirmed: true/false payloads for reorg safety | Reorg handling built into the pipe |
| Replay / history (limited) | Full backfill: the same feed serves history and live data (how backfill works) |
Why teams move
- No delivery infrastructure. No public webhook endpoint, no signature checks, no retry handling, no ingestion queue. Data lands in your database directly.
- History and live in one pipe. A new stream starts at “now”; a feed backfills as deep as you need, then stays live.
- Consume it your way. The same feed can flow into Postgres today and your own Kafka, AMQP, or SQS consumers as the platform’s export options roll out; see What are Data Feeds? for the consumption model.
Try the model now
You can evaluate Data Feeds against your current Streams setup today:- Run the quickstart: live decoded data in your own Postgres in about ten minutes.
- Find the recipe closest to what your stream watches (token transfers, contract logs, swaps, NFT activity).
- Keep your stream running in parallel while you compare; nothing about trying Data Feeds disturbs your existing Streams setup.

