How Memgraph 3.11 Simplifies Multi-Tenancy for Cross-Database Graph Workloads

A team starts with one graph for one product, customer, domain, or AI system. Then the use case grows. More teams adopt it. More customers come in. Data needs to stay isolated. Access needs to be controlled. Production needs monitoring. High availability becomes non-negotiable. That is where multi-tenancy helps.

But it also creates a new problem: once data lives across multiple databases, working with it can become harder than it should be.

You still need to answer questions across boundaries. You still need to move data safely. You still need to know which database is causing load. You still need secure communication inside the cluster. Memgraph 3.11 focuses on that problem.

This release makes it easier to work with graph data across multiple databases while keeping the isolation, visibility, and control that production systems need.

Query Across Databases Without External Stitching

Memgraph 3.11 introduces the **cross_database** module, which lets you reach into another database from a running Cypher query and stream rows into Memgraph.

That matters because workflows that span multiple databases is usually where multi-tenant systems become more complex.

Without a database-level path, teams often have to:

• Query one database
• Pull results into application code
• Query another database
• Match or reshape the data externally
• Push the result somewhere else

That might work once. It becomes fragile when the workflow turns into a repeated operational pattern.

With cross-database querying, Memgraph can handle more of that work closer to the data. This helps when you need to migrate data, compare environments, build hybrid pipelines or read from another source without adding extra code to connect everything together.

So, teams can keep database boundaries without making every cross-boundary workflow a custom integration project.

Use Virtual Graphs When You Need a Temporary View

Multi-tenant systems also create a second kind of problem. Sometimes you do not need to move data permanently. You only need a temporary graph view to answer a question, test a model or run a graph algorithm over a derived structure.

Creating another stored graph for every temporary view adds overhead. It also creates more objects to manage, clean up and explain later.

Memgraph 3.11 adds support for virtual graph views through derive(). A virtual graph is useful when you want to work with a graph-shaped view without writing that structure back into storage.

That makes sense for workflows such as:

• Testing how derived relationships affect algorithm results
• Exploring tenant-specific subsets or comparing graph structures across databases
• Running analysis or investigations without modifying production data

This makes it easy to explore and experiment without any complexity.

Observe and Secure Multi-Tenant Workloads

Multi-tenant systems need both visibility and secure operations. Memgraph 3.11 adds per-database labels to the OpenMetrics endpoint, so teams can monitor each database separately in tools like Prometheus and Grafana. This makes it easier to identify which database is causing load instead of relying on instance-level metrics.

It also improves visibility with slow and failed query logging and richer transaction and storage insights, helping teams understand how each workload behaves.

For high availability deployments, Memgraph 3.11 introduces intra-cluster TLS, securing communication between coordinators, data instances, and replicas. TLS certificates can also be reloaded without restarting nodes, making rotation easier in production environments.

Together, these updates help teams monitor, debug, and secure multi-tenant graph workloads more effectively.

Wrapping Up

The core value of Memgraph 3.11 is that it makes multi-tenant graph workloads more practical to work with in production.

You can keep data separated across databases without making every cross-database workflow a custom application problem. You can create temporary graph views without persisting unnecessary structures. You can monitor workloads at the database level. You can secure internal HA communication as those deployments grow.

That combination matters because graph workloads often become more valuable as they become more connected. But they also become harder to operate if the system does not give teams enough control.

Memgraph 3.11 helps close that gap. It gives teams a more practical way to work across graph databases while preserving the boundaries that production systems need.

For the complete list of updates, technical details and upgrade guidance, see the Memgraph 3.11 release notes.