Why a separate instance per boutique
Confidentiality between peers should not rest on a shared tenant identifier. Here is why Rempart gives each M&A boutique its own instance.
Most white-label tools put all their clients in a single database. Each client is isolated by an identifier, the “tenant”, checked on every request. On paper, that is enough. In a business where two competing boutiques may advise both sides of the same table, it is not.
The risk of a shared identifier
When everyone shares the same database, a single filtering mistake, a single poorly siloed query, and one boutique's documents become readable by another. Control rests entirely on application code, run correctly every time, without exception. That is not an acceptable bet for a sell-side file.
What Rempart does
Each boutique gets a separate instance: its own database, its own storage, its own domain and its own emails. Two boutiques' documents never share the same database. The separation is not a column in a shared table, it is a real boundary.
Inside an instance, critical rights are enforced by the database itself, through PostgreSQL RLS, not only in the interface. A member reads only the folders and documents allowed for their role and group.
The cost, and why it is worth it
One instance per boutique is heavier to operate than a single database. It is a deliberate choice: confidentiality between peers is the product's central promise, and it must not depend on the discipline of an application filter. Rempart's white label is therefore not just a skin: it is end-to-end separation.