UTXO query by address will soon be deprecated?

[cffls]

While browsing the documentation of Ogmios, I saw a warning section under state query, saying that

Filtering UTXO by address is no longer recommended with the introduction of on-disk ledger state storage. Filtering by output reference is preferred.

Does it mean UTXO query by address will be removed in the next major release of Ogmios? Or is it simply not recommended but will still be supported?
As a user, I would really like to keep this feature, because it allows me to use Ogmios as a single point of service to interact (read/write) with the blockchain. If the feature is removed, I will need to bring in other services or components, e.g. db-sync, to be able to query the blockchain for some use cases, which complicates the architecture.

By the way, I really appreciate that you are spending your part time building Ogmios, which is extremely helpful and a true gem for the community. Thank you, Matthias!

[KtorZ]

Hey @cffls, it is deprecated because I was informed that the ledger team is also deprecating this query now that the ledger is moving to on-disk storage.

The UTxO is indexed by output references, not by addresses. This means that, searching by address requires a linear scan of the UTxO which is getting big. This is why on 1.33.0 that query has got a major performance hit (traversing millions of entries in the RAM is okay-ish, doing it from the disk is worse)... If it is eventually removed from the ledger, then sadly, I'll have to follow and remove it from Ogmios as I'd have no (sane) way to support this.

However, I have been aware of this issue for a while now and... bear with me for a few more days 😊

[cffls]

By the way, do you think it makes sense to integrate kupo into Ogmios so that "query by address" functionality still remains and can be even faster/more efficient with the help of kupo?

[KtorZ]

I see them more as complementary solutions; small building blocks that one may chose to include in its stack or not.

I like this "micro" service approach where we can have many small tools at our disposals which works well together but are very modular for apps which can use them "à la carte".

[cffls]

Totally agree with the importance of modularity. I was thinking towards making Ogmios configurable, so users can turn on or off Kupo according to their use cases. However, the same thing could be also achieved by creating a third service on top of Ogmios and Kupo. Just putting up some ideas for discussion.. Thanks for the quick response!

[KtorZ]

(@cffls if your question has been answered, may I invite you to mark it "answered" 🙏)

[cffls]

Just did. Thank you for the kind reminder!