<p>Hi there (Kupo's maintainer here)!</p>
<p>Given the use case you're describing, Scrolls seems the most suited solution at present -- especially because this is exactly the direction Scrolls is moving into.</p>
<p>We've been discussing that on several occasions with Santiago (Scrolls' maintainer), and we try to not overlap too much between Scrolls and Kupo; both solutions emerged roughly around the same time and we're now trying to make them focus on a different set of use cases.</p>
<p>About the N2C in Scrolls, keep in mind that the project is open source and I am sure that you'd find either the resources to implement it or, if kindly ask, you may have maintainers or community-members consider prioritizing it.</p>
<p>Regarding Oura &amp; Ogmios, you're right that they are more fundamental building blocks, not indexers, but they would allow you to build your own indexer should Kupo or Scrolls not meet your needs in the end.</p>
<p>Carp is a good alternative to db-sync, probably overkill for small projects.</p>
<p>Marconi, as far as I can tell, is Kupo with less features and less documentation. I wasn't aware that this project even existed (and... now a bit baffled to be honest).</p>

CC BY-SA 4.0
2022-10-18T10:15:08.967Z
Thanks, I appreciate the feedback!
Will
CC BY-SA 4.0
2022-10-18T10:05:54.713Z
2022-10-18T10:05:54.713Z
KtorZ
<p>Agree with all that's been said already, just important (unfortunate) gap to highlight (since we're talking about comparison), most of the solutions are not able to fetch certain offline or historical information from ledger-state, tho that is a limitation that comes from consensus/ledger teams instead - and a very non-trivial piece of work to keep up with.</p>
<p>So while things like historical reward history, epoch nonce, etc may not useful to all (especially in DeFi world), other solutions (for instance Carp) unfortunately do not exactly qualify as alternative/replacement to dbsync yet - tho hoping things improve on that front all around.</p>

CC BY-SA 4.0
2022-10-20T07:57:18.497Z
Good point! I didn't particularly mention it bc we don't require those data points for the solution we're looking to build. But you're right db-sync as of now offers complete ledger state access such as rewards etc. that most other tools do not include.
Will
CC BY-SA 4.0
2022-12-09T07:34:36.433Z
An interesting follow-up conversation on this topic: https://github.com/cardano-foundation/CIPs/pull/375
KtorZ
CC BY-SA 4.0
2022-10-20T05:11:14.540Z
2022-10-20T05:11:14.540Z
RdLrT
<p>I have been taking a look at different chain indexers (or APIs to indexers) to see what's available today and how they differ - see resource list below.</p>
<h2>Question</h2>
<p>I still wanted to raise the question, <strong>what would be a good option for an event-based backend</strong> (not necessarily written in Haskell) that shall process on-chain events as they happen. In particular, we want to observe certain addresses and aggregate on-chain data using an CQRS / event sourcing architecture.</p>
<h4>My current take</h4>
<p>I wouldn't want to poll data via REST which makes <strong>Kupo</strong> and <strong>Blockfrost</strong> not an ideal candidate.</p>
<p><strong>Oura</strong> looks like a great candidate but from what I see, it's not really indexing and much rather filtering on event types (like blocks, txs, assets etc.) and would still require some more processing on the backend to actually get the data I am interested in. What I like about it is that it support Node-to-Client (N2C) communication.</p>
<p><strong>Scrolls</strong> as of now looks like a great candidate as it offers <em>opinionated read-optimized views</em>. I would imagine a Redis centered event store architecture combined with <a href="https://redis.io/docs/data-types/streams-tutorial/" rel="noreferrer">Redis Streams</a>. The only thing I'd love support for is N2C which looks like is not yet implemented with <a href="https://github.com/txpipe/scrolls#feature-status" rel="noreferrer">version 0.4.2</a> mainly for improved performance.</p>
<p><strong>Ogmios</strong> looks also very attractive as it would easily allow for a Node.js backend that could connect via websockets to directly read from the node. It's not an indexer I believe, but more an interface to the node. Hence, it requires additional filtering/ indexing in the backend similar to <strong>Oura</strong>.</p>
<p><strong>Carp</strong> by dcSpark looks interesting too. It indexes and stores everything to a Postgres db, allows for N2C. Might very well be one of the strongest candidates and most likely complete in terms of development.</p>
<p>Lastly, <strong>Marconi</strong> looks like the best alternative to <strong>Scrolls</strong> &amp; <strong>Carp</strong> unless I am forgetting about some other available resource. It's Haskell based and unfortunately, as of now has no event streams implemented. It will offer it in the near future.</p>
<h3>Summary</h3>
<p>In short, it looks like the available options are still very early in development but very promising. Nevertheless, I would appreciate feedback, things I've missed or other advice from the community!</p>
<p>Thanks!</p>
<h2>Resources</h2>
<ul>
<li><a href="https://cardanosolutions.github.io/kupo/#section/Overview" rel="noreferrer">Kupo</a></li>
<li><a href="https://github.com/txpipe/oura" rel="noreferrer">Oura</a></li>
<li><a href="https://github.com/txpipe/scrolls" rel="noreferrer">Scrolls</a></li>
<li><a href="https://github.com/input-output-hk/plutus-apps/tree/main/marconi" rel="noreferrer">Marconi</a></li>
<li><a href="https://docs.blockfrost.io/" rel="noreferrer">Blockfrost</a></li>
<li><a href="https://ogmios.dev/" rel="noreferrer">Ogmios</a></li>
<li><a href="https://github.com/dcSpark/carp" rel="noreferrer">Carp</a></li>
</ul>

<plutus><chain-index><chain><backend>
Chain Indexers with Stream Endpoints
# Chain Indexers with Stream Endpoints

(Asked by: username_0 on 2022-10-18)

I have been taking a look at different chain indexers (or APIs to indexers) to see what's available today and how they differ - see resource list below.

## Question

I still wanted to raise the question, **what would be a good option for an event-based backend** (not necessarily written in Haskell) that shall process on-chain events as they happen. In particular, we want to observe certain addresses and aggregate on-chain data using an CQRS / event sourcing architecture.

#### My current take

I wouldn't want to poll data via REST which makes **Kupo** and **Blockfrost** not an ideal candidate.

**Oura** looks like a great candidate but from what I see, it's not really indexing and much rather filtering on event types (like blocks, txs, assets etc.) and would still require some more processing on the backend to actually get the data I am interested in. What I like about it is that it support Node-to-Client (N2C) communication.

**Scrolls** as of now looks like a great candidate as it offers *opinionated read-optimized views*. I would imagine a Redis centered event store architecture combined with [Redis Streams](https://redis.io/docs/data-types/streams-tutorial/). The only thing I'd love support for is N2C which looks like is not yet implemented with [version 0.4.2](https://github.com/txpipe/scrolls#feature-status) mainly for improved performance.

**Ogmios** looks also very attractive as it would easily allow for a Node.js backend that could connect via websockets to directly read from the node. It's not an indexer I believe, but more an interface to the node. Hence, it requires additional filtering/ indexing in the backend similar to **Oura**.

**Carp** by dcSpark looks interesting too. It indexes and stores everything to a Postgres db, allows for N2C. Might very well be one of the strongest candidates and most likely complete in terms of development.

Lastly, **Marconi** looks like the best alternative to **Scrolls** & **Carp** unless I am forgetting about some other available resource. It's Haskell based and unfortunately, as of now has no event streams implemented. It will offer it in the near future.

### Summary

In short, it looks like the available options are still very early in development but very promising. Nevertheless, I would appreciate feedback, things I've missed or other advice from the community!

Thanks!

## Resources

* [Kupo](https://cardanosolutions.github.io/kupo/#section/Overview)
* [Oura](https://github.com/txpipe/oura)
* [Scrolls](https://github.com/txpipe/scrolls)
* [Marconi](https://github.com/input-output-hk/plutus-apps/tree/main/marconi)
* [Blockfrost](https://docs.blockfrost.io/)
* [Ogmios](https://ogmios.dev/)
* [Carp](https://github.com/dcSpark/carp)

**Tags:** plutus, chain-index, chain, backend

---

## 2 answers

### Answer by username_1 on 2022-10-18. Score: 9 | Accepted answer

Hi there (Kupo's maintainer here)!

Given the use case you're describing, Scrolls seems the most suited solution at present -- especially because this is exactly the direction Scrolls is moving into.

We've been discussing that on several occasions with Santiago (Scrolls' maintainer), and we try to not overlap too much between Scrolls and Kupo; both solutions emerged roughly around the same time and we're now trying to make them focus on a different set of use cases.

About the N2C in Scrolls, keep in mind that the project is open source and I am sure that you'd find either the resources to implement it or, if kindly ask, you may have maintainers or community-members consider prioritizing it.

Regarding Oura & Ogmios, you're right that they are more fundamental building blocks, not indexers, but they would allow you to build your own indexer should Kupo or Scrolls not meet your needs in the end.

Carp is a good alternative to db-sync, probably overkill for small projects.

Marconi, as far as I can tell, is Kupo with less features and less documentation. I wasn't aware that this project even existed (and... now a bit baffled to be honest).

> **Comments:**
> **username_0**: Thanks, I appreciate the feedback!  

---

### Answer by username_2 on 2022-10-20. Score: 1

Agree with all that's been said already, just important (unfortunate) gap to highlight (since we're talking about comparison), most of the solutions are not able to fetch certain offline or historical information from ledger-state, tho that is a limitation that comes from consensus/ledger teams instead - and a very non-trivial piece of work to keep up with.

So while things like historical reward history, epoch nonce, etc may not useful to all (especially in DeFi world), other solutions (for instance Carp) unfortunately do not exactly qualify as alternative/replacement to dbsync yet - tho hoping things improve on that front all around.

> **Comments:**
> **username_0**: Good point! I didn't particularly mention it bc we don't require those data points for the solution we're looking to build. But you're right db-sync as of now offers complete ledger state access such as rewards etc. that most other tools do not include.  
> **username_1**: An interesting follow-up conversation on this topic: https://github.com/cardano-foundation/CIPs/pull/375  

---

