Understanding Database Connection Pooling in a Bold BI® Environment

Overview

Bold BI stores application and tenant information in a relational database such as Microsoft SQL Server, MySQL, PostgreSQL, or Oracle.

When a user accesses a dashboard, page, or scheduled job, database operations are performed to retrieve the required information. Database providers use connection pooling to efficiently manage database connections and reduce the overhead of creating new connections for every operation.

Note: A single page request may execute multiple SQL queries. Depending on workload and connection pool availability, these operations may reuse existing pooled connections or temporarily utilize multiple active database connections during request processing.

How Connection Pooling Works

Database connection pooling allows application services to reuse existing database connections instead of creating and closing a new connection for every request. When a database operation is completed, the connection is returned to the pool and made available for future requests. This reduces connection establishment overhead and improves overall performance.

Factors That Affect Database Connections

The total number of active database connections depends on:

• Number of tenants
• Number of concurrent users
• Dashboard complexity
• Number of SQL queries executed
• Scheduled jobs and exports
• Database server connection limits
• Other applications sharing the same database server

Single User Access

When only one user is active, database connection usage is generally low because requests are processed sequentially.

Concurrent User Access

As the number of concurrent users increases, more database operations may be processed simultaneously, increasing the number of active database connections.

Multi-tenant Deployment Models

Shared Database

All tenants share the same database.

Tenant A
Tenant B  ---> Shared Database
Tenant C

Considerations

• All tenants use the same database resources.
• All requests target the same database server.
• Shared database resources can increase the likelihood of reaching database connection limits during periods of high activity.
• Activity from one tenant can affect overall database performance.

Recommended For

• Smaller deployments
• Limited tenant count
• Moderate concurrency

Dedicated Databases on a Shared Database Server

Each tenant has a dedicated database, but all databases reside on the same database server.

Database Server
├─ TenantA_DB
├─ TenantB_DB
├─ TenantC_DB
└─ TenantD_DB

Considerations

• Provides better tenant-level isolation.
• All tenant databases still share the same database server resources.
• Connections from all tenants contribute to the server’s total connection count.
• Other applications hosted on the same server can also consume available connections.

Recommended For

• Medium-sized multi-tenant deployments

Dedicated Databases on Dedicated Database Servers

Each tenant uses an independent database server.

Tenant A → Server A → Database A
Tenant B → Server B → Database B
Tenant C → Server C → Database C

Considerations

• Database resources are isolated per tenant.
• Connection limits are managed independently on each server.
• Lower risk of connection contention.
• Provides the best scalability for large deployments.

Recommended For

• Large-scale SaaS deployments
• High-concurrency environments

Important Sizing Considerations

When investigating connection-related issues, review:

• Multi-tenant activity
• Average concurrent sessions
• Dashboard and Data source activity
• Scheduled jobs and exports
• Database server connection limits
• Database maintenance activities
• Other applications using the same database server

In multi-tenant deployments, connection-related errors are frequently associated with database server capacity limits, connection configuration settings, or overall workload demands across tenants and applications.

Database Configuration References

Review your database server’s connection limits and capacity planning settings.

Microsoft SQL Server

Monitor:

• User Connections
• Worker Threads

Documentation:
https://learn.microsoft.com/sql/database-engine/configure-windows/configure-the-user-connections-server-configuration-option

MySQL

Monitor:

• max_connections

Documentation:
https://dev.mysql.com/doc/refman/en/server-system-variables.html#sysvar_max_connections

PostgreSQL

Monitor:

• max_connections

Documentation:
https://www.postgresql.org/docs/current/runtime-config-connection.html

Oracle

Monitor:

• SESSIONS
• PROCESSES

Documentation:
https://docs.oracle.com/en/database/

Monitoring Database Connections

When investigating database connection usage, monitor both the current active connection count and peak connection utilization on the database server. This information can help identify whether connection limits, workload spikes, or resource contention are contributing to performance issues.

Recommendations

For better scalability in multi-tenant environments:

1. Monitor database connection usage regularly.
2. Configure database connection limits based on expected concurrency.
3. Consider separate databases as tenant count increases.
4. For large deployments, use dedicated database servers per tenant.
5. Include other applications sharing the same database server when planning capacity.

Key Takeaway

Bold BI relies on the database provider’s connection pooling mechanism to efficiently manage database access. The total number of active database connections depends on tenant count, concurrent user activity, dashboard workloads, scheduled jobs, and database server capacity. As multi-tenant deployments grow, dedicated databases and dedicated database servers provide greater isolation, scalability, and control over connection usage.