While working with an ERP system for a manufacturing company, I’ve repeatedly seen how appealing multi-tenant architecture appears initially, only to incur unexpected costs in the long run. Management often focuses on initial licensing and infrastructure costs, but invisible expenses like operational overhead, security risks, and performance issues are frequently overlooked.
In this post, I will discuss the true costs, technical, and operational challenges of a multi-tenant ERP solution, drawing from my own experiences. I believe that when making a choice, one should look not only at the initial costs but also at long-term sustainability and the burden on teams.
The Initial Appeal: Why Multi-Tenant?
Multi-tenant architecture allows multiple customers (tenants) to share a single software instance and the same underlying infrastructure. It’s often preferred in SaaS (Software as a Service) models because it promises efficient resource utilization and reduced costs. For example, you can host data for multiple customers using different schemas or tables on the same PostgreSQL server.
In my manufacturing ERP project, we were initially drawn to the appeal of this model. Low upfront costs, rapid deployment capabilities, and scalability potential sounded very attractive, especially for small and medium-sized businesses. We thought we could serve hundreds of customers by managing a single infrastructure, which at first glance seemed to reduce the operational burden.
Data Isolation and Security: The Invisible Risks
Perhaps the most critical and often overlooked aspect of multi-tenant architecture is data isolation and security. Even though you share the same infrastructure, it’s imperative that each tenant’s data is completely isolated and secure from others. In my career, I’ve witnessed how a flawed design in this area can lead to a major crisis. Once, due to an incorrect query optimizer setting, another tenant’s product information briefly appeared in one tenant’s report. Fortunately, this was noticed early and resolved without a major disaster, but the potential reputational damage and legal issues gave me considerable pause.
There are multiple strategies to ensure data isolation: separate databases, separate schemas, filtering by tenant ID in a shared schema, or using Row-Level Security (RLS). In our manufacturing ERP, we initially used tenant ID filtering and later transitioned to RLS integration. RLS offers a powerful mechanism in PostgreSQL 9.5 and later versions, but configuring it correctly and ensuring it works for every query requires significant engineering effort. Furthermore, maintaining audit logs and tracking who accessed each tenant’s data and when is an operational burden in itself.
-- PostgreSQL'de Row-Level Security (RLS) örneği
-- Policy oluşturmadan önce RLS'i etkinleştir.
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
-- Tenant ID'ye göre erişimi kısıtlayan policy
CREATE POLICY tenant_isolation_policy ON orders
USING (tenant_id = current_setting('app.current_tenant_id')::int);
-- Uygulama tarafında tenant ID'yi set etmek
SET app.current_tenant_id = 123;
-- Bu noktadan sonra, 'orders' tablosuna yapılan tüm sorgular
-- otomatik olarak tenant_id = 123 ile filtrelenir.Such mechanisms, when implemented correctly, enhance security but can also add overhead to database performance and cause unexpected behavior in complex queries. It’s crucial to understand how RLS behaves, especially when using an ORM. Otherwise, you might encounter performance issues like the N+1 query problem I mentioned in my post ORM traps.
Performance and Resource Management: One ‘Bad Neighbor’ Is Enough
One of the biggest drawbacks of multi-tenant architecture is performance fluctuations caused by shared resources. A single tenant’s intensive operation can affect all other tenants using the same physical server or database instance. I call this the ‘bad neighbor syndrome.’ Once, a new client initiated a large data transfer, which increased reporting and data entry times across the entire ERP system by 30-40% for about 2 hours.
To manage this situation, we must define resource isolation and limits. Cgroups in Linux offer a powerful tool for this. By assigning each tenant to its own cgroup, we can impose limits on CPU, memory, and I/O resources. However, this configuration and monitoring process is quite complex. For example, you can set a tenant’s memory.high limit as a soft limit, allowing the system to try slowing down that tenant before killing other tenants during crises.
# Bir cgroup oluşturma ve limitler atama örneği
# /sys/fs/cgroup/memory/tenant_A dizinini varsayalım
sudo mkdir /sys/fs/cgroup/memory/tenant_A
sudo sh -c "echo 200M > /sys/fs/cgroup/memory/tenant_A/memory.limit_in_bytes" # 200MB hard limit
sudo sh -c "echo 180M > /sys/fs/cgroup/memory/tenant_A/memory.high" # 180MB soft limit
sudo sh -c "echo 100000 > /sys/fs/cgroup/memory/tenant_A/memory.kmem.limit_in_bytes" # Kernel memory limit
sudo sh -c "echo <process_id> > /sys/fs/cgroup/memory/tenant_A/tasks" # Process'i cgroup'a ekle
# CPU limitleri için cpu cgroup'u
sudo mkdir /sys/fs/cgroup/cpu/tenant_A
sudo sh -c "echo 100000 > /sys/fs/cgroup/cpu/tenant_A/cpu.cfs_period_us" # 100ms periyot
sudo sh -c "echo 20000 > /sys/fs/cgroup/cpu/tenant_A/cpu.cfs_quota_us" # 20ms CPU kullanımı (20% CPU)Such detailed cgroup settings imposed a significant additional burden on me as a system administrator. I had to monitor each tenant’s resource consumption individually, detect anomalies, and intervene manually when necessary. This is a complexity you wouldn’t encounter in a single-tenant model, where each tenant has its own isolated infrastructure rather than a single shared database or application server. Especially when we experienced PostgreSQL performance regressions, finding which tenant caused the problem sometimes took us days.
Customization and Version Management: The Price of Flexibility
Every ERP customer has unique workflows and reporting needs. In a multi-tenant structure, developing custom features for each customer can make the general codebase unsustainable. We tried to solve this situation with feature flags and modular architecture. That is, we used switches that allowed a feature to be turned on or off for a specific tenant. For example, when we developed a special “production planning algorithm” for a customer, we added a feature flag to activate it only for that tenant.
However, even this approach significantly complicated version management and testing processes. With each new release, testing hundreds of different tenant combinations increased the risk of regressions. A customization made for one tenant could accidentally break another tenant’s system. Because of this, I constantly had to improve our deployment strategies (blue-green, canary) and rollback automation.
This led me to the conclusion that software architecture is often more about organizational flow than just software. Before adding a feature, it was crucial to carefully consider how it would affect other tenants, extend testing processes, and increase operational overhead. Otherwise, a small customization request could turn into a development and testing cycle lasting months.