Multi-Tenancy in Graph Databases and Why Should You Care?

By Marko Budiselic

5 min readMay 6, 2025

What is Multi-Tenancy?

Multi-tenancy is one of those terms that sounds fancy but boils down to a simple concept: multiple users or organizations (tenants) sharing the same system while remaining logically isolated. Gartner defines it as:

“Multitenancy is a reference to the mode of operation of software where multiple independent instances of one or multiple applications operate in a shared environment. The instances (tenants) are logically isolated but physically integrated.”

In the world of databases, this means multiple users, applications, or storage units coexist without stepping on each other’s toes.

Why Does It Matter for Databases?

A Database Management System (DBMS) is more than just a place to store data—it’s a collection of databases with a system managing them. Once you start sharing resources across multiple users or applications, you’re effectively running a multi-tenant system.

Here’s why that matters:

Centralized management of multiple database instances simplifies administration.
Instead of spinning up separate databases for every user, you can consolidate storage and computational resources.
Multi-tenancy ensures that one database engine can serve multiple clients, reducing overhead while maintaining isolation.

In simpler terms, multi-tenancy allows:

Multiple databases/storage backends can exist within the same system.
Multiple users can work simultaneously without interfering with each other.
Multiple applications can connect to the same backend while keeping their data separate.

Concepts and Tradeoffs

Multi-tenancy brings both advantages and tradeoffs, especially for in-memory systems. Here are some key considerations.

Single Instance vs. Multiple Small Instances

A single instance setup centralizes resource management but creates a single point of failure. If the instance crashes, all tenants suffer. Running many small instances isolates tenants but increases memory overhead and operational complexity.

Key Tradeoffs

Resource utilization. If data is stored on disk, a server can use the same RAM to serve multiple database requests with minimal additional overhead. However, in-memory databases (like Memgraph) require careful RAM balancing between tenants.
Reliability. A multi-tenant system can be replicated for resilience, but all tenants are affected if the system goes down.
Security. Centralized data access means better governance, but also higher risk if the security model is not robust. Snowflake, for example, embraced multi-tenancy early on, allowing features like Enterprise Data Sharing, **a massive value proposition.
Maintainability. System upgrades instantly benefit all tenants, but breaking changes affect them all simultaneously.

Real-world Examples of Multi-Tenancy

To put things into perspective, the easiest way to understand multi-tenancy is using Slack as an example.

Slack

If you’ve used Slack, you’ve experienced multi-tenancy in action. Each workspace is a separate tenant, logically isolated from others. That’s why you can have separate workspaces for different companies, and data doesn't leak between them.

Now, Slack Connect allows users from different workspaces to communicate. This is where multi-tenancy gets tricky. Instead of just having isolated tenants, they need to interact while maintaining security and performance. (Disclaimer: We don’t know exactly how Slack implemented this, but it’s safe to assume that multi-tenancy plays a role.)

Multi-Tenancy in Databases

Different database systems implement multi-tenancy in various ways. Let’s examine Postgres, one of the most popular open-source relational databases.

Multi-Tenancy in Postgres

PostgreSQL is well-known for its flexibility in handling multi-tenant architectures. You’ll often see guides on configuring Postgres for multi-tenancy:

Schema-based multi-tenancy, ****where each tenant gets a separate schema within the same database.
```
CREATE schema tenant_one;
SET search_path TO tenant_one, public;
```
This approach keeps tenant data separate while allowing shared resources like connection pooling.
Row-level security where instead of separate schemas, you can tag each row with a tenant ID and enforce access control at the row level.

For a deeper dive, check out these resources:

Multi-Tenancy in Graph Databases

Graph databases, including Memgraph, introduce additional complexities when dealing with multi-tenancy. Unlike relational databases, where tables and schemas naturally lend themselves to isolation, graphs are all about relationships—meaning data separation needs to be carefully managed.

Some ways graph databases handle multi-tenancy include:

Creating separate graph instances per tenant (similar to separate schemas in Postgres)
Tagging nodes and edges with tenant IDs to enforce logical separation
Enforcing access control policies to prevent cross-tenant queries

The right approach depends on the use case. Are you running a SaaS platform where each customer needs a completely isolated dataset? Or do you need some tenants to interact while maintaining strong access controls?

Multi-Tenancy in Memgraph

The multi-tenancy feature allows you to host multiple graph databases within a single Memgraph server instance. Each graph remains completely isolated from the others.

This capability delivers significant cost savings, reducing maintenance overhead and infrastructure complexity. Multi-tenancy is currently available in the Enterprise version of Memgraph.

How Multi-Tenancy Works in Memgraph

Here’s everything you need to know summarized in one short video. For details, I recommend you read our Memgraph docs here.

Performance Considerations in Multi-Tenancy

Running multiple databases consumes more memory, but at least you won’t have tenants stepping on each other's queries. Since CPU and RAM are shared, you’ve got to keep an eye on workloads—one rogue tenant hogging resources can ruin it for everyone. Also, always query the right database instead of defaulting to memgraph; it makes indexing and caching way more efficient, which means faster queries and less frustration.

Conclusion

Multi-tenancy touches many aspects of database architecture. Before implementing it, ask yourself:

What are your application requirements and operational capabilities?