I’m Marko, CTO at Memgraph. This post was written by my colleague Matt, and I can help answer questions about the migration and the reasoning behind it.
The post covers why we moved parts of our infrastructure to Hetzner, including cost, operational overhead, and performance consistency. One of the main takeaways for us was that dedicated infrastructure gave us more predictable benchmarking and reduced some of the maintenance burden we previously had with a colocated setup.
Happy to answer questions about the tradeoffs, what worked well, and what we’d do differently.
Hi all! I'm Marko, CTO at Memgraph, and the author of this post.
The post argues that the GraphRAG pipeline can be expressed as a single database query rather than a chain of application-layer steps. The idea is to keep components such as retrieval, expansion, ranking, and final context assembly within the database query plan.
I go through:
* what I mean by GraphRAG in practice;
* why "single-query" execution can reduce moving parts;
* why can that help with latency/cost by returning only the final payload;
* and how it can make tracing/debugging easier by returning the context plus the path used to assemble it.
The post also contrasts this with Python-orchestrated pipelines and touches on agentic pipeline selection (called Agentic GraphRAG). Happy to answer technical questions or discuss where this breaks down.
Hi all - I’m Marko, CTO at Memgraph. The author of this post, David, also works at Memgraph.
This post explains how our vector index is implemented within the same storage engine as the graph (eliminating the need for a separate vector store), how we avoid double vector storage, and how scalar type choices (f32/f16/etc) affect memory usage. It also covers some implementation details (USearch-backed index, concurrency, and recovery behavior).
We included a benchmark on 1M nodes with 1024-dim embeddings comparing versions 3.7.2 and 3.8.0, and saw large RAM reductions in the newer version while keeping load and response times similar. Happy to answer technical questions.
Agree with the measures; follow-up question: what's the insight definition? I think exposing some of those measures would help people better understand what the analysis covered, in other words, how much data was actually analyzed. Maybe an additional measure is some kind of breadth (I guess it could be derived from the throughput).
"Informational leverage" reminded me of "retrieval leverage" because yeah, the scale of data didn't change, the ability to extract insights did :D
This is like saying: "Here we have a rocket, but let's keep trying to go to the moon by bike." xD
What's wrong with attempting to better understand a given organization using LLMs or any other tech? Ofc, great managers will try as hard as possible to talk face to face as much as possible.
DISCLAIMER: The co-founder and CTO of Memgraph here.
To add more context, Memgraph Enterprise pricing is explained under https://memgraph.com/pricing: "Starting at $25,000 per year for 16 GB, Memgraph has an all-inclusive, simple pricing model that scales with your workload without restrictions. No charge for compute. No charge for replicas. No charge for algorithms. No Surprises.".
In addition, Memgraph Community is free (standard BSL license, which turns into Apache2 4 years after release date, https://github.com/memgraph/memgraph/blob/master/licenses/BS...), and it has many features that are usually considered enterprise (users, replication, not a single degradation in performance or scale, etc.).
Please elaborate more about why the pricing seems expensive, or put it into the infra-cost perspective :pray:
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.
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.
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 :)
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?
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!
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
The post covers why we moved parts of our infrastructure to Hetzner, including cost, operational overhead, and performance consistency. One of the main takeaways for us was that dedicated infrastructure gave us more predictable benchmarking and reduced some of the maintenance burden we previously had with a colocated setup.
Happy to answer questions about the tradeoffs, what worked well, and what we’d do differently.