mbuda

Memgraph's CTO here, thanks for the feedback

under Memgraph's implementation of multi-tenancy each database is isolated, meaning that vector search indices are also isolated per database (each db has it's own set of vector indices)

the same limitations apply as to multi-tenancy or vector search (e.g. multitenancy includes some kind of routing, but that's minimal overhead because database is picked per session; importing large vectors can be slower but that's nothing to do with multi-tenancy), there is nothing specific to that combination (to my knowledge)

on your specific use-cases side, I think it's about combining data from multiple databases, that's primarly a multi-tenancy concern, limitation there is that Memgraph can't execute queries across multiple databases in a single query yet (ofc you can manage that on the application layer), there are also options like: cross-database query module -> https://memgraph.com/docs/advanced-algorithms/available-algo..., or Memgraph Zero (totally new product, federated GQL / semantic layer for agents) -> https://memgraph.com/docs/memgraph-zero

getting offtopic xD, I hope the above helps :D

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.

Interesting! What are the next released features? In particular, I'm curious how can this help me to build my own skills :thinking:

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.

Love it!

Yep, amazing points!

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

Here are clickable links: https://youtu.be/ygr8yvIouZk?t=1307, https://adamdrake.com/from-enterprise-decentralization-to-to...

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:

The author here. This is just the shortest (in terms of size) reasoning about the topic. Any feedback and discussion is welcome!

It's not possible to escape tradeoffs. To deal with tradeoffs, focus is important. API to tradeoffs is also important.

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

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.

Please join our Discord at https://discord.gg/memgraph, more people will be able to help you there :)

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!

Don't know about SQLite, https://github.com/apache/age seems very interesting, but it's just a tiny layer on top of Postgres :)

I guess the question which part of cyber attach data you can visualize and how?

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 Memgraph founder/leader.

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 haven't put a false statement and hid the code. 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 one our customers have most often (mixed highly concurrent read/write with real-time analytics), and we perform well on it. 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) has no that type of limits, and that's also something we want to highlight as Memgraph's competitive advantage. So, all this is about comparing offerings rather than the underlying tech. Even if you take Neo4j Enterprise (which Max did, which is much less fair), Memgraph has an advantage.

It takes time, but szarnyasg and I will convince you otherwise :)

"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.

LDBC is really great, it is and it should be the standard non-biased benchmark to look at. The point with https://memgraph.com/benchgraph is to be more tilted towards some specific workloads, easy to extend and run, etc. Time will tell to which extend that could be achieved, but definitely a place to look for some interesting workloads and results. + the whole thing is super early and it's going to evolve!

Again, definitely take a look at LDBC benchmarks they are in general the most relevant.