Multi-Tenant vs Multi-Instance: Why We Chose Isolated Mautic Installations Over a Shared Database

When you're building a platform that serves multiple organizations, one of the earliest and most consequential architectural decisions is how to handle tenancy. Do you put everyone in one database and separate their data with a tenant_id column? Or do you give each tenant their own database, their own application instance, and their own isolated environment?

We chose isolation. Each tenant on our white-label Mautic platform runs as a fully independent Mautic installation - own database, own configuration, own pods, own lifecycle. And we'd make the same choice again.

But this isn't a post arguing that multi-instance is always better. It's a post about understanding the trade-offs, knowing when isolation makes sense, knowing when it doesn't, and seeing how we built a hybrid architecture that captures the benefits of isolation while mitigating its costs.

Defining the Terms

These terms get used loosely, so let's be precise about what we mean.

Multi-tenant (shared database): All tenants share a single database. Data is separated by a tenant_id column (or similar partition key) on every table. One application instance serves all tenants. This is the classic SaaS model - think Slack, Salesforce, or most modern SaaS products.

• Lowest infrastructure cost per tenant
• Most complex data isolation
• Shared application lifecycle (all tenants on the same version)
• Cross-tenant features are natural (aggregation, comparison, global admin)

Multi-instance (isolated): Each tenant gets their own database and their own application instance. They share infrastructure (the Kubernetes cluster, the network) but nothing at the application layer.

• Higher infrastructure cost per tenant
• Simplest data isolation (separate databases = zero risk of cross-tenant data leaks)
• Independent lifecycle per tenant (different configurations, theoretically different versions)
• Cross-tenant features require additional infrastructure

Hybrid (what we built): Shared infrastructure - Kubernetes cluster, monitoring, deployment tooling, email sending services - with isolated application and data layers. Each tenant is a fully independent Mautic installation, but they all run on the same platform.

Why Isolation Won for Mautic

Our decision wasn't ideological. It was driven by four practical factors specific to our situation.

1. Data Isolation Is Non-Negotiable

The tenants on our platform are independent organizations. In many cases, they serve overlapping or competing audiences. A data leak between tenants - even an accidental one, even a small one - would be catastrophic for trust and potentially for legal compliance.

With a shared database, cross-tenant data isolation depends on every query, every report, every export, and every admin tool correctly filtering by tenant_id. One missed WHERE clause, one unfiltered API endpoint, one admin dashboard that doesn't scope its queries - and you have a data breach.

With isolated databases, cross-tenant data access is architecturally impossible. There's no tenant_id column to forget. The databases are separate systems. A bug in one tenant's code can't accidentally expose another tenant's data because the data simply isn't there.

For a marketing automation platform that stores contact lists, email engagement data, and behavioral tracking information, this level of isolation isn't paranoia - it's a requirement.

2. Mautic Wasn't Designed for Shared-Database Multi-Tenancy

This is the pragmatic factor. Mautic is an open-source marketing automation platform built to run as a single installation for a single organization. Its database schema, its caching mechanisms, its configuration system - none of these were designed with tenant_id partitioning in mind.

Retrofitting multi-tenancy into Mautic's core would have meant modifying hundreds of database queries, reworking the caching layer, adjusting the file storage system, and maintaining a permanent fork of the application. Every Mautic upgrade would require re-applying these modifications and testing for regressions.

Instead of fighting the application's architecture, we worked with it. Each tenant gets a standard Mautic installation - no core modifications required. Upgrades are applied to the shared codebase and rolled out to all instances without tenant-specific patches.

3. Performance Isolation Eliminates the Noisy Neighbor Problem

On a marketing automation platform, workloads are inherently bursty. One tenant might send a million emails on Monday. Another might run a complex segmentation query that scans their entire contact database. A third might be idle.

With a shared database, these workloads compete for the same resources. Tenant A's million-email campaign generates write load that slows down Tenant B's contact import. Tenant C's segmentation query locks tables that Tenant D needs for real-time tracking.

With isolated instances, each tenant's workload affects only their own resources. Tenant A's email blast runs against their database, on their pods, using their allocated CPU and memory. Tenant B's operations are completely unaffected.

This isolation isn't just about fairness - it's about predictability. Each tenant experiences consistent performance regardless of what other tenants are doing.

4. Independent Operations Simplify Everything

Isolated instances mean independent operations:

• Debugging is straightforward. A problem with one tenant is contained to their instance. Logs, database queries, resource usage - everything is scoped to a single installation.
• Backups and restores are per-tenant. Need to restore Tenant C's database to yesterday's state? Do it without affecting anyone else.
• Custom configuration is natural. One tenant needs a specific PHP setting, a different email processing configuration, or a custom plugin enabled. No problem - it's their instance.
• Incident isolation is built in. If one tenant's instance has issues - a runaway cron job, a database corruption, a misconfigured integration - the blast radius is limited to that single tenant.

The Cost of Isolation - and How We Mitigate It

Multi-instance architecture has real costs. Pretending otherwise would be dishonest. Here's what isolation costs us and what we do about it.

More Infrastructure Per Tenant

Each tenant requires their own database, their own application pods, their own cron jobs, and their own queue consumers. That's more infrastructure than a shared-database approach.

Mitigation: We run on a mix of on-demand and spot instances, saving 50-65% on compute costs. We carefully right-size resource allocations per tenant based on actual usage. Our per-instance cost came in at approximately $90/month - below our initial estimate of $120/month. The platform is designed to scale to 300-500 tenant instances on the same shared infrastructure.

Deployment Complexity

When you push an update, it needs to reach every tenant instance. With a shared application, you deploy once. With isolated instances, you deploy dozens of times.

Mitigation: Argo CD with wave-based deployments. A single codebase is built into a Docker image, and Argo CD rolls it out across all instances using canary groups. The first batch of instances serves as the test group. If the canary is healthy, the rollout continues automatically. One codebase, one build, many deployments - orchestrated by automation.

Provisioning Overhead

Adding a new tenant to a shared-database system means inserting a row. Adding a new tenant to a multi-instance system means provisioning a database, creating Kubernetes resources, configuring DNS, setting up monitoring, and running the Mautic installer.

Mitigation: Fully automated provisioning. A new tenant instance goes from zero to operational in 7-8 minutes with zero manual intervention. The process creates the database, generates the Kubernetes manifests, configures the DNS entry, deploys the application, runs the installer, and verifies the health check - all triggered by a single command.

Monitoring Complexity

Instead of monitoring one application, we're monitoring dozens of independent instances, each with their own health indicators.

Mitigation: Centralized observability with Prometheus, Grafana, and Loki. All instances report to the same monitoring stack. We track 671 metrics across the platform, with dashboards that give us both platform-wide views and per-tenant drill-downs.

What We Share: The Hybrid Model

Calling our architecture "multi-instance" undersells the shared infrastructure layer. Here's what's shared across all tenants:

• Kubernetes cluster. All tenant workloads run on the same EKS cluster. Namespace isolation separates tenant resources logically.
• Deployment tooling. One Helm chart serves as the template for all tenant instances. Per-tenant differences are configuration values, not separate templates.
• Monitoring stack. Single Prometheus/Grafana/Loki installation monitors all instances.
• Email sending infrastructure. Shared Mailgun domain with per-tenant sender configurations and tracking.
• AWS services. Shared SQS queues, S3 buckets, and Route 53 DNS - with per-tenant configuration for isolation at the application level.
• CI/CD pipeline. One Docker image built from one codebase, deployed to many instances.

This hybrid approach gives us the data isolation benefits of multi-instance with the operational efficiency of shared infrastructure. The expensive parts (Kubernetes cluster, monitoring, CI/CD) are amortized across all tenants. The per-tenant costs (database, pods) are optimized through automation and right-sizing.

When to Choose Multi-Instance

Multi-instance is the right choice when:

• Data isolation is a hard requirement. Regulatory compliance, competitive sensitivity, or contractual obligations demand that tenant data is physically separated.
• The application wasn't designed for multi-tenancy. Retrofitting tenant_id into an existing application is expensive, risky, and creates an ongoing maintenance burden.
• Tenants have significantly different scales. If one tenant has 10,000 contacts and another has 10 million, isolated instances let you right-size each one independently.
• You need independent lifecycle management. Different configurations, independent maintenance windows, per-tenant customizations.
• Your automation can handle the operational overhead. Multi-instance is only viable if provisioning, deployment, and monitoring are highly automated.

When Shared Database Makes More Sense

Multi-instance isn't universally superior. Shared-database multi-tenancy is better when:

• You have thousands of very small tenants. If per-tenant cost must be minimal (pennies, not dollars), shared database is the only way.
• The application is designed for multi-tenancy from the ground up. If the software already has robust tenant isolation in its data layer, you're working with the architecture instead of against it.
• All tenants run identical configurations. No per-tenant customizations, no independent lifecycle management.
• You need cross-tenant features. Global analytics, cross-tenant comparisons, marketplace features - these are natural in a shared database and require significant extra infrastructure in a multi-instance setup.

The Decision Framework

There's no universally right answer. The choice depends on your specific product, your tenants, your application, and your team's capabilities.

For us - building a white-label platform on an open-source application that wasn't designed for multi-tenancy, serving organizations that require strong data isolation - multi-instance was the pragmatic choice. The key was investing in automation to make the operational overhead manageable: automated provisioning, orchestrated deployments, centralized monitoring, and shared infrastructure where isolation isn't needed.

The architectural pattern is: isolate where it matters (data, application, performance), share where it's efficient (infrastructure, tooling, monitoring). That hybrid approach gives you the safety of isolation without the full cost.

Building Your Multi-Tenant Strategy

If you're evaluating multi-tenancy approaches for your own platform - whether it's built on Mautic, Drupal, or another open-source foundation - the decision deserves careful analysis. The wrong choice creates years of technical debt. The right choice creates a foundation that scales with your business.

[Get in touch](https://www.droptica.com/contact/) to discuss your architecture. We've built multi-instance platforms from the ground up and can help you evaluate the trade-offs for your specific situation.