Hello,

I am evaluating the best option to allow users of our SaaS platform to create their own dashboard, however I can not find if with Redash it could:

  • Our platform is multi-client, in all the tables this is the ID of the account and we would have to ensure that it automatically adds in all the querys in an automatic way the company_id = X (the ID of the company account of the specific user that obviously we must pass to Redash in some way) in order to guarantee that users can not see information from another customer account (company).

Is this possible? Any idea how I could do it in Redash?

Thanks for any help.

Bump! I’m evaluating different dashboards at the moment and came across this.

It would be great to hear your experience @andres84, or anyone from the redash team.

Thanks very much.

Hi @andres84
I’m new to this forum - and Redash, but I’ve set up dashboards and databases like you are describing. There are a couple ways to do it, but a key principle is that the access has to be managed on the server - you can’t trust browser-based apps to manage access to server resources because they are too easily hackable. So the solution you end up with will almost certainly require a unique login and password for each customer. Here are two approaches that should work with Redash:

  1. (more secure): sync tables into customer-specific databases and give each customer their own unique database, each with its own access control policies and user accounts. At HQ, your staff can still have access to the common table with all customer data. With separate databases and separate access to each database, you minimize the risk of data leaks between customers. If those databases live on different servers or VMs, you further reduce the risk that one customer’s query creates a deadlock, or extreme slowdown, that could cause an outage for other customers. Separate servers also permits additional layers of security such as firewall rules. If your customers are security-conscious, and/or you are required to perform security audits, this may be the only practical option.

  2. (secure, but more error prone) If your database supports views, you could create a view of the common table for each customer that filters rows and only exposes the rows applicable to the customer. The permissions are set up so that each customers’s login can read its own view, and none of the other views, and has no access to the common table. Setting up new clients could be an automated process, as doing all these steps can be error prone.
    This method still has risk of deadlock or slow queries from one customer affecting availability of the database for others.

One thing you need to be careful of is related data tables. If your main table is “Orders” and you have client ID column in the Orders table to track which client made the order, you can filter rows of the Orders table using one of the methods above. However, if there Order table has a ProductCategory field, and values in the ProductCategory field are chosen from a shared Categories table, you might risk leaking category names from one customer to another unless the Categories table also has a clientId field. A thorough review of the schema may be needed to ensure there are no leaks of this type.

Another issue that comes up in multi-tenant databases is that caches are less efficient. Client A’s data displaces B’s data in the database’s in-memory caches, and visa-versa, so alternating queries between clients may reduce the benefits of caching. There are a lot of factors that influence cache behavior, so this may or may not be an issue for you. If you end up with unexpectedly slow performance this may be one of the areas where tuning is needed.
Hope that helps!