I am a fan of anyone that is willing to produce a pay per drink database service with good performance that scales. It lowers the barrier to small players to do big things. If I had to pay for every GB of index that needs to sit in memory for the life of my product, well thats not the kind of innovation I am looking for basically.
Slash is pay per GB transferred and scales with transfer vs overall size of indexes.This is currently the main factor after graph orientation that motivates me to use Slash GraphQL over other services. I would love to see more focus on this, maybe a blog post and also assurances we will not get slapped with a change in model down the road would be really nice.
Can you clarify what is unique about Dgraph that enables you to make this pricing available?
Can you illustrate the performance of Dgraph and especially Slash as index sizes scale?
Does Slash face any cold-start issues as perhaps workers spin up or data is paged into memory?
Finally along the lines of reducing runtime cost for operating large indexes, I noticed this gem today on Hacker News PGM Indexes: Learned indexes that match B-tree performance with 83x less space | Hacker News perhaps this is applicable to Dgraph indexes?
Thanks in advance for any insights!