Comment by dietr1ch
2 months ago
Graph DB OOMing 101. Can it do Erdős/Bacon numbers?
Graph DBs have been plagued with exploding complexity of queries as doing things like allowing recursion or counting paths isn't as trivial as it may sound. Do you have benchmarks and comparisons against other engines and query languages?
No, we are in the process of writing up some proper benchmarks. Our first user used us to build MuskMap and TrumpMap, which went viral on twitter. Not sure how it compared to other graph DBs at the time (bear in mind this was v1 and very bear bones), but it got latency of using Postgres >5s down to 50ms with us.
What are MuskMap and TrumpMap (I'm kind of afraid to ask), and can you link to more info about how they used your database?
They were two viral web apps that blew up on twitter. They had approx 25,000 users at their peak.
Originally they were built on Postgres, so we helped move over to us. Their graph had about 50,000 user nodes and 25 million edges (follower connections). This then made it a lot more optimised to handle the highly interconnected users to find shortest paths between one user and Elon Must / Donald Trump.
So to sum it up, they stored clones of all the users and how they were interconnected by follower relationships, and then used our query language to super easily calculate the shortest paths.