You can choose isolated vs shared at different levels, depending on what's important to your customers. In one app, we do schema isolation. For each tenant we create a schema and a db user with access to only that schema. Both of these match the tenant id. Before we run any query, we get the tenant associated with the user and switch to the tenant's db user/schema. So no cross-tenant access is possible. But this is a pain when you need to query across tenants. Example: to get billable usage by tenant, have to run a query per schema and union them together. And we have to run a provisioning process before new tenants can access it.
If you go with full isolation, you can customize code, data structures, operational guarantees, etc. per customer. But it's the most expensive way -- you have to maintain each customized version. And resources can sit idle (wasted cost) much of the time.
Shared (pooled) resources are the most economical, but data isolation is more of a challenge. Examples: row-level security, but it may affect data design. Encrypt each tenant's data with a separate key. Bake tenant filtering into the code infrastructure.
Things get more complicated when arbitrary connections between entities allow access. Such as an accepted friend request. You might use make-shift graph tables and recursive CTEs in small apps or a graph database in larger apps to trace access. Example: Alice -(friend)-> Bob -(post)->Vacation -(attachment)-> Photo123.jpg. Found a path, so Alice is allowed to open the photo.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a primer here.
You can choose isolated vs shared at different levels, depending on what's important to your customers. In one app, we do schema isolation. For each tenant we create a schema and a db user with access to only that schema. Both of these match the tenant id. Before we run any query, we get the tenant associated with the user and switch to the tenant's db user/schema. So no cross-tenant access is possible. But this is a pain when you need to query across tenants. Example: to get billable usage by tenant, have to run a query per schema and union them together. And we have to run a provisioning process before new tenants can access it.
If you go with full isolation, you can customize code, data structures, operational guarantees, etc. per customer. But it's the most expensive way -- you have to maintain each customized version. And resources can sit idle (wasted cost) much of the time.
Shared (pooled) resources are the most economical, but data isolation is more of a challenge. Examples: row-level security, but it may affect data design. Encrypt each tenant's data with a separate key. Bake tenant filtering into the code infrastructure.
Things get more complicated when arbitrary connections between entities allow access. Such as an accepted friend request. You might use make-shift graph tables and recursive CTEs in small apps or a graph database in larger apps to trace access. Example: Alice -(friend)-> Bob -(post)->Vacation -(attachment)-> Photo123.jpg. Found a path, so Alice is allowed to open the photo.