as additional information to the Joseph Pollone reply.

It depends on what you need, it can be simpler or more complex.

If you only want to separate the data by customer (user), without them managing their own users, you can create a customers table linked to auth.users (schema.table). Similar to this examples. Instead of profiles, create customers

And then, in each data table, you create a field called customer_id to link which customer the data belongs to.

Then you configure RLS policies for each table so that only the owning customer can access its data. Example:

create policy \"Customers can view their own cars.\"\non cars for select\nusing (auth.uid() = customer_id );

create policy \"Customers can view their own customer data\"\non customers for select\nusing (auth.uid() = id);

On the other hand, if you want each client to manage its own users, the idea is similar to the above, but this time you separate the data by tenant or organization. Take a look at custom_claims (but can also be used for any type of multi-tenancy).

When you create views, it is important to create them with the security_invoker = true because:

'if the view has the security_invokerproperty set to true, access to the underlying base relations is determined by the permissions of the user executing the query, rather than the view owner. Thus, the user of a security invoker view must have the relevant permissions on the view and its underlying base relations.
If any of the underlying base relations is a security invoker view, it will be treated as if it had been accessed directly from the original query. Thus, a security invoker view will always check its underlying base relations using the permissions of the current user, even if it is accessed from a view without the security_invoker property.

Data per customer with FF / Supabase