We’re planning a large-scale Polarion deployment for multiple business units and I’m evaluating multi-tenant vs single-tenant architecture. Our requirements include 8 business units, approximately 500 users total, and strict data isolation for compliance reasons.
I’ve been researching the configuration inheritance model in multi-tenant setups and how it impacts LDAP integration. From what I understand, multi-tenant offers better resource utilization and centralized management, but I’m concerned about horizontal scaling limitations and health monitoring complexity.
For those running pol-2310 or similar versions in production, what’s been your experience with multi-tenant scaling? How does configuration inheritance work when each tenant needs customized workflows and permissions? And how do you handle LDAP integration when different business units use different authentication sources?
Curious to hear real-world experiences on performance trade-offs and operational overhead between these two approaches.
One aspect people often overlook is health monitoring granularity. In single-tenant setups, each instance has its own monitoring endpoints and you can track resource usage per business unit easily. Multi-tenant requires custom monitoring to track per-tenant metrics - database query counts, API call rates, background job execution times. Out-of-the-box monitoring tools don’t provide tenant-level visibility, so you’ll need to instrument your deployment with custom metrics collection.
I’d recommend single-tenant if compliance and data isolation are top priorities. Multi-tenant is great for cost efficiency, but you’re sharing database connections, application server resources, and background job queues. We had issues with health monitoring in multi-tenant where one tenant’s heavy workload caused performance degradation across all tenants. Diagnosing which tenant was causing the problem required custom monitoring scripts.
We run a multi-tenant setup with 6 tenants on pol-2310 and it’s been solid. The configuration inheritance is hierarchical - you define base configurations at the system level and override at tenant level. For LDAP integration, each tenant can have its own authentication realm, so multiple LDAP sources aren’t a problem. The key is proper namespace isolation and resource quotas to prevent one tenant from impacting others.
For LDAP integration with multiple sources, we use a hierarchical approach. Each tenant has its own LDAP realm configuration, and we map organizational units to tenants. The configuration inheritance lets you define common LDAP settings (connection timeout, SSL settings) at the system level, then override specific settings like base DN and bind credentials per tenant. This works well for 6 tenants, but I imagine managing 8+ would require automation scripts for configuration management.
In pol-2310, horizontal scaling works well with multi-tenant if you configure it properly. Tenants aren’t pinned to nodes - the load balancer distributes requests across all application servers. The challenge is session affinity and caching. You need sticky sessions at the load balancer level and a distributed cache solution like Redis for tenant-specific configuration data. Otherwise, you’ll see inconsistent behavior when requests for the same tenant hit different nodes.
That’s helpful context. The compliance concern is real for us - we need audit trails that clearly separate tenant data. How does horizontal scaling work in multi-tenant? Can you add application server nodes and have the load balancer distribute tenants across nodes, or are tenants pinned to specific server instances?