Building multi-tenant workspaces in PostgreSQL — what would you do differently?

Day 6 of building Verso (projectoye.com)
A workspace OS that brings Notes, Spreadsheets, Presentations, Process Flows, and an AI-native IDE into one place.

Today was a schema day.
No UI. No demos. Just PostgreSQL and hard decisions.

What I worked on

Verso needs to support:

• Solo users

• Teams

• Enterprises

…all from the same codebase.

That means the schema must handle:

• Tenant isolation (no data bleed between organizations — ever)

• Multiple workspaces per tenant

• User roles that vary by workspace (not just tenant-level)

• Private spaces (like Grid — a personal canvas invisible even within the same tenant)

The hierarchy I landed on

Tenant → Organization → Workspace → User → Document

Every row in the database carries a tenant_id.

• PostgreSQL Row-Level Security (RLS) enforces isolation

• The application layer adds a second layer of checks

The question I am still thinking about

Is Row-Level Security alone enough, or should every query also enforce tenant_id at the application layer as a belt-and-suspenders approach?

Looking for insights

If you have shipped a multi-tenant SaaS on Postgres, I would love to know:

What do you wish you had done differently at the schema stage?

→ projectoye.com
Think without limits.