When you are planning on releasing your retool apps to multiple clients, considering multi-tenancy is a fundamental step. The least thing you want is for your client A to be able to see and modify its competitor data, right? Retool offers flexibility in building multi-tenant systems, but choosing the right approach depends on your requirements for security, cost, and maintenance.
In this article, we’ll explore three ways to implement multi-tenancy in Retool:
- Simple tenant isolation using a single Retool space with database-level multi-tenancy
- Multiple Retool spaces (cloud enterprise) for each tenant
- Multiple on-premise Retool instances for complete isolation
1. Tenant Isolation via Database-Level Multi-tenancy in a Single Retool Space
One common method for multi-tenancy is to use a single Retool space and handle tenant isolation at the database level. This approach reduces overhead by maintaining a single Retool environment while managing tenant-specific data in the backend.
The Challenge:
Retool’s resource configuration doesn’t allow you to pass dynamic data to your database connection directly, such as tenant identifiers. The database connection is static and accepts only username and password. Therefore, passing the tenant ID dynamically is impossible unless you include it in every query.
The Solution:
Use PostgREST or a gateway between Retool and your database. By placing an intermediary between your Retool app and the database, you can manipulate requests to include the tenant information dynamically. PostgREST, for example, allows you to expose your database through a RESTful API, making it easier to inject the necessary tenant data.
2. Multi-tenancy with Multiple Retool Spaces (Cloud Enterprise)
For larger organizations or SaaS platforms serving few big clients, using multiple Retool spaces is a more organized and isolated approach. Each tenant gets access to a separate Retool space, which has a completely isolated set of users, permissions and settings from the rest of your Retool infrastracture.
How it works:
Each Retool space is connected to a separate database or schema, and you can pass tenant information through the database connection. For example, you could use the tenant’s username as the database user and build row-level security (RLS) policies based on this.
This approach simplifies tenant-specific customizations, including user permissions, role management, and feature toggles, without affecting other tenants.
Advantages:
- Separate permissions and settings for each tenant. (Can be automated with Retool API)
- Easier to manage tenant-specific customizations.
- RLS policies can be enforced at the database level based on the tenant’s username.
Disadvantages:
- Requires synchronization between spaces, which can be achieved with Github source control.
- Price: it requires Retool enterprise plan, so it is going to be more expensive.
- Maintaining source control can be challenging when each space requires frequent updates.
3. Full Isolation with Multiple Retool Instances (Self hosted Retool plan)
For those seeking the highest level of security, deploying multiple on-premise Retool instances, one per tenant, is the most secure option. This setup is particularly useful for industries that require strict data isolation (e.g., finance or healthcare) or for large enterprises with high customization demands.
How it works:
Each tenant has their own Retool instance, completely isolated from others, running on-premise in a Docker Container or similar. Coupling this with a separate database for each tenant, ensures the maximum level of tenant isolation.
Advantages:
- Maximum security and tenant isolation.
- Full customization capabilities for each tenant.
- Lowest risk of data leakage between tenants.
Disadvantages:
- High infrastructure costs and overhead.
- Requires significant maintenance for each instance, which can be simplified with Retool API.
- Version control and feature rollouts can become complex
Conclusion: Choosing the Right Approach for Your Multi-tenant Platform
The right approach for multi-tenancy in Retool depends on your organization’s requirements. If you need a cost-effective solution and are comfortable handling isolation at the database level, tenant isolation in a single Retool space with PostgREST can work. For those with stricter requirements and complex needs, multiple spaces in Cloud Enterprise Retool may be ideal. And for top-tier security, full isolation with multiple on-prem instances is the best choice.
What is the most scalable multi-tenancy approach in Retool?
In our opinion, using a gateway between Retool and your database, or using PostgREST (with a service like Supabase) will guarantee the best scalability, because the infrastructure does not get more complicated the more tenants you have.
What is the pricing for Retool on premise?
Retool pricing can be complex, view our article about retool pricing here to learn more.
Leave a Reply