[yamalight]

That looks pretty neat, although not all things are exactly clear.

1. You claim that existing graph databases were not fast enough - do you have any benchmark data that compares them with your solution on given dataset?

2. From the description - it seems like you are focusing purely on Person type of data - is that correct? Or is that just the first use case / demo?

3. Do you support more advanced query langs, e.g. SPARQL?

edit: formatting

[skafoi]

1. We indeed made benchmarks when we started with this. But since this is quite some time ago, I would not call for the exact numbers right now. For our use case, there are basically two extrems. a) everything being the same data: assuming proper deduplication happened, meaning having one node and everything else is still one node away without being connected with each other, then this is still the case where graph databases work quite ok (somewhere around 6 seconds if i remember correctly) b) having a long chain of data: A->B->C->D (in that use case basically a person who moves very often). beside having to write an utterly complex query for that, I remember that I was not able to receive any results within an excaptable time.

2. That is only for that use case. But the underlying matching library we developed can work together with any kind of structured data. It would be interessting to actually use it in some other contexts as so far we have not tested that out yet.

3. Currently no - pure GraphQL api currently. But I was thinking about that. In order to actually support something like this, it would be very interessting to also focus on cross entity linking to make it really cool. We have something like this, but didn't really focus on that yet.

[yamalight]

1. Since there are plans to open source - would be very interested to see benchmarks published alongside code!

2-3. Got it, thanks!