I guess when you compare pure performance of hardware, 10x is very optimistic from the perspective of disk. Probably the author based this number on some some specific application/database context / bias in the measurements. But yea, pure hardware difference might be hugely different compare to that number.
I'm glad that you liked it. If you want to see all of these things in action check out Memgraph. You, can find our repo at https://github.com/memgraph/memgraph DISCLAIMER: I'm the co-founder and CTO.
Also, any feedback or suggestion will help us push more of content like this in the future!
Thanks for this intro to Graphs. Does Memgraph persist to disk or is it in-memory only? If in-memory only, do you have plans to support graphs which become larger than available memory? Thanks!
Yes, memgrpah persists data on-disk, but there is not the support for larger than memory datasets yet (but a lot can fit on a single machine). In general, our primary focus at the moment is the scale out / proper graph sharding support. The progress on that side can be tracked under the following project -> https://github.com/orgs/memgraph/projects/5
How big is your graph and do you have specific queries in mind?
It depends on a few things. If you want to migrate all the data that's heavier than just, e.g., the graph part and connections. It heavily depends on the final model, required data types and overall distribution of data. This guide -> https://memgraph.com/docs/memgraph/under-the-hood/storage can help you with calculating the amount of required RAM. Also, we plan to include a simple calculator into the next release of Memgraph Lab (https://memgraph.com/docs/memgraph-lab/) coming probably this wee :)
Thank you so much! One more question if you'll permit me - and then I'll leave you alone I promise. Social networks are often recommended as a use-case for a graph database. How well would Memgraph perform on generating an activity feed of all of the posts of the people I follow ordered by post date descending, for example (hopefully with pagination)?
Hard to say without a particular query, and again it depends on the model, but from the explanation, that could be modeled as a 2-hop relationship. If you put in-place indexes and maybe some filtering, it should be fast.
Memgraph does persist data. Snapshots are taken periodically during the entire runtime of Memgraph. When a snapshot is triggered, the whole data storage is written to the disk. There are also write-ahead logs that save all database modifications that happened to a file.
I'm CTO at Memgraph it's very nice to see us on the list :D Thanks Fireship! You can checkout all of the info about MG at https://memgraph.com + happy to figure out more about your graph streaming use-cases!
Just got back from CIDR conference and I wanted to share few of my thoughts and takes. Recordings and slides also got published in the meantime -> https://www.cidrdb.org/cidr2023/program.html
DISCLAIMER: I'm a cofounder and the CTO at Memgraph.
The workload and software used to benchmark are public on Github, which means they can be validated and tested. Memgraph as a company is committed to improving Memgraph and benchmarking further. That's why, in addition to other reasons, we raised funding. We have made no false statements and our findings are replicable. Everything, Memgraph source code + benchmark methodology, is public.
Benchmarks are always workload dependent and we always encourage people to test on their workload. The workload in the benchmark closely resembles the ones our customers have most often (mixed highly concurrent read/write with real-time analytics), and we perform well on it. Our default Snapshot Isolation consistency level further enables a vast class of applications to be built on top of our system which would simply break due to the weak consistency guarantees of legacy graph databases. That's precisely the reason why our customers choose us. You should always test on your workload because your mileage may vary and Memgraph might not be the right fit for you.
The main reason Memgraph is performing that much better is that Neo4j Community Edition 5.0 is limited for anybody in terms of how it uses available resources. On the other side, Memgraph Community (equivalent offering, it's not 100% the same, but it's closest to compare, no two systems are the same) does not restrict the performance of our public offering, and that's also something we want to highlight as just one of Memgraph's competitive advantages. So, all this is about comparing offerings rather than the underlying tech. Even if you take Neo4j Enterprise (which Max did, on completely different hardware, which is... "creative"), Memgraph has an advantage.
"egregious example" is unfair because there was and will be a huge effort in comparing different options. Ofc it's biased. Every single benchmark is biased towards something, but take a look at the specifications and what has actually being compared.
100% agree that everyone should run their own benchmark, that's not possible to do from the vendor perspective, it's just not possible for every single usage. Public benchmarks are something to look into if you want to get cheap info on how different vendors might do for you. Huge but is that it's just a guide, not the only piece of info you should base your decision on.
I bet somebody will raise a similar question in a few years time when the list under https://db-engines.com/en/ranking/graph+dbms will be bigger.
DISCLAIMER: Coming from https://github.com/memgraph/memgraph