Memgraph: an in-memory C++ graph engine for GraphRAG and streaming analytics
High-performance open-source in-memory graph database for GraphRAG, AI memory, agentic AI, and real-time graph analytics. Cypher-compatible, built in C++.
At a glance
- What is it?
- Memgraph puts vector and text indexes in the same query layer as Cypher traversal, which lets retrieval pipelines run as one database operation. The trade-off is that the licence is not a single OSI-approved file, and everything lives in memory.
- Who is it for?
- Adopt Memgraph if your retrieval or analytics workload is traversal-heavy and you can keep the working set in RAM, and if you are willing to read the licence files before shipping. Do not adopt it if you need a plain single-licence open source dependency, or if your data does not fit in memory.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The retrieval split that Memgraph is built to close
A typical GraphRAG pipeline today is two systems stitched together in application code. A vector store answers the similarity query, then the application takes the returned identifiers and asks a graph database to expand them. The join happens in Python or TypeScript, which means two round trips, two failure domains, and a ranking step that cannot see the graph structure at the moment it scores candidates. The README frames the alternative directly: Memgraph provides "built-in text and vector indexes for similarity search combined with full graph traversal, so retrieval pipelines can run as a single atomic database operation instead of being scattered across multiple systems."
That is the specific problem. It is aimed at teams building AI memory, agent context stores, and GraphRAG retrieval, plus operational teams doing fraud detection, network analysis and infrastructure monitoring where the same traversal engine is reused. The README describes the second group as workloads "where performance matters", and lists fraud detection and network analysis among them. If your queries are single-hop lookups by key, none of this applies to you and a relational store will be simpler.
How the engine is put together: in-memory storage, Cypher, and custom modules
The core is written in C and C++ and holds the graph in memory rather than on disk. That single choice explains most of the rest of the design. The README claims "sub-millisecond multi-hop traversals" and points to a benchmark page at memgraph.com/benchgraph for the numbers; the repository itself does not contain a benchmark harness you can read to check that claim, so treat the figure as a vendor statement until you reproduce it on your own data.
On top of that storage layer sits a Cypher query layer, described as fully compatible with Neo4j's Cypher. The README states the database is ACID-compliant. Query execution is parallel, which the README lists as "concurrent query processing for high-throughput workloads".
Extensibility comes through query modules. The README says these can be written in Python, Rust and C/C++, and that they load natively. The MAGE library in src/mage is the shipped example: the README describes it as 40+ graph algorithms in C++, Python and CUDA, naming PageRank, community detection, GNN-based link prediction, temporal graph networks and embeddings. That list is worth reading carefully. Several of those items are machine learning workloads running inside the database process, not classic graph algorithms, which is a much larger surface for a query module than a shortest-path function.
For ingestion, the README documents native Parquet and JSONL loading from local disk, S3 or HTTP endpoints, and streaming from Kafka, Pulsar and RedPanda. The streaming path is described as supporting "dynamic graph algorithms that react to changes in real time", which is the same MAGE module mechanism applied to a stream rather than a batch.
Schema introspection is exposed as a query: SHOW SCHEMA INFO returns what the README calls "the full graph ontology", intended for Text2Cypher and agent integration. That is a small feature with an outsized effect on agent tooling, because it lets a model discover labels and relationship types instead of being told them.
Getting a node running: Docker, packages and Helm
The README does not give a single canonical install command. It routes by platform. On Windows the documented paths are Docker and WSL. On macOS they are Docker and lima. On Linux there are Docker, Debian, Ubuntu, CentOS, Fedora and RedHat entries, with the RPM-based distributions sharing one install page. For Kubernetes the README points at the official Helm charts repository and gives this example:
helm repo add memgraph https://memgraph.github.io/he
The README text is truncated at that point, so the chart names and the follow-up helm install invocation are not visible in the material I have. You will need the charts repository for the release name and values file. The README also links a browser-based Playground at playground.memgraph.com, described as requiring no installation, which is the fastest way to check whether the Cypher dialect matches what you already write.
This is the weakest part of the README as a document. There is no docker run line, no default port, no statement of what the container expects for persistence or memory limits. For an in-memory database, the memory limit is not a detail. If you are evaluating this, the install pages under memgraph.com/docs are the real entry point, not the README.
The licence is three files, and that is an adoption cost
The repository metadata reports the licence as NOASSERTION, which is the accurate label. The README displays three badges: APL, BSL and MEL, linking to licenses/APL.txt, licenses/BSL.txt and licenses/MEL.pdf. APL is presumably the Apache Licence, BSL the Business Source Licence, and MEL a Memgraph-specific licence distributed as a PDF.
I cannot tell you from the supplied material which parts of the codebase fall under which file, or what the MEL terms permit. A PDF licence is a deliberate choice: it is harder to diff in a pull request and harder to grep in CI. If you are running a licence scanner, expect it to flag this repository, and expect to resolve the flag by reading the files rather than by trusting a SPDX identifier.
This is not a reason to avoid the project. It is a reason to treat licence review as a scheduled task with an owner rather than a checkbox. A BSL component typically carries a change date and use restrictions that a permissive licence does not, and those restrictions can bite a commercial deployment that assumed otherwise. I am not giving legal advice here; the point is that the material does not let me tell you the answer, and it will not let your scanner tell you either.
Where Memgraph is the wrong tool
The in-memory design is the limitation. A graph that fits comfortably in RAM is fast; a graph that does not will either fail to load or push you into swap, and the README says nothing about how Memgraph handles a working set larger than available memory. There is no documented disk-backed storage mode in the material I have. If your graph grows past the machine, the answer is a bigger machine, and that ceiling arrives without warning.
Durability is a related question the README does not answer in the text I can see. It lists backup and restore under Enterprise features and describes Raft-based coordination with automatic failover for high availability, but the standalone story for persistence across a restart is not stated here. Before you put anything you cannot rebuild in it, read the docs on snapshotting and write-ahead logging.
Second, the feature list leans hard toward AI workloads, and that framing can mislead. If you want a graph database for a straightforward recommendation engine or an org chart, the vector indexes, the LLM utility module and the AI Toolkit are weight you will not use. A smaller embedded graph library may serve you better and will not require a server process.
Third, the enterprise features are named but not specified. Multi-tenancy, label-based permissions at the node and edge level, SSO, impersonation, and "30+ granular permissions" are all listed in one paragraph. Whether any of those are available in the build you install, versus gated behind a commercial edition, is not stated in the README. Assume nothing until you check the docs for the specific version.
How it differs from Neo4j
The obvious comparison is Neo4j, and the README invites it by advertising Cypher compatibility. The difference is in the storage engine. Neo4j's mainstream editions are disk-based with page caching, which means the graph can be larger than RAM and performance degrades gradually as the cache hit rate falls. Memgraph holds the graph in memory, which removes that degradation curve but replaces it with a hard capacity wall. Neither is better in the abstract; they fail differently.
The second difference is where the AI retrieval primitives live. Memgraph ships vector and text indexes inside the same query layer as traversal, and the README's claim is that pivot search, graph expansion, ranking and prompt assembly can be "expressed as a single Cypher query". With Neo4j you would typically pair the database with a separate vector index and orchestrate the two from application code, unless you adopt Neo4j's own vector index feature. The Memgraph pitch is that the atomicity is the point: one query, one transaction, one ranking step that can see both similarity scores and graph structure.
A third difference is the extension model. Memgraph query modules accept Python, Rust and C/C++ and run in-process. That is a different posture from a plugin ecosystem built around a JVM, and it matters if your team writes Rust or modern C++ rather than Java.
Where Neo4j wins is ecosystem maturity and the breadth of tooling built around it. That is not a benchmark, it is an observation about what you will find when you search for a driver, a migration guide, or an answer to an error message.
Upgrade cadence and what it costs you
The release history shows a steady rhythm: v3.11.0 in June 2026, v3.12.0 in July 2026, v3.13.0 in September 2026. Roughly every six to eight weeks, with a minor version bump each time. The repository was last pushed in September 2026 and is not archived.
That cadence has a cost. A minor version every two months means you are either upgrading regularly or falling behind on a moving target, and for a database that means testing your query modules against each release. If you write custom query modules in Python, Rust or C++, they are compiled or loaded against the engine, and an internal API change can break them. The README does not describe a stability guarantee for the module interface.
The Helm chart path adds a second version axis. The charts live in a separate repository, so your chart version and your engine version move independently, and you need to track both. For a high-availability deployment using the Raft coordination described in the README, that is a rolling upgrade you should rehearse rather than discover.
On the plus side, the daily build workflow is public, and a Playground sandbox lets you test a query against a current build without touching your own infrastructure. Use it to check whether a syntax you rely on survives the next minor version.
Editorial conclusion
Adopt Memgraph if your retrieval or analytics workload is traversal-heavy and you can keep the working set in RAM, and if you are willing to read the licence files before shipping. Do not adopt it if you need a plain single-licence open source dependency, or if your data does not fit in memory. Verify first: which of APL, BSL and MEL applies to the version you intend to run, and whether your vector search and graph traversal really need to be one atomic query.
Community notes