Users and permissions
Invite teammates and scope what they can do.
Databasin has two levels of membership: organization (the tenant) and project (a workspace inside the org). This article covers the roles that actually exist today, where each one is managed, and how permissions flow.
The hierarchy
Organization
├── Organization users ← everyone who can log in
├── Projects
│ ├── Project users ← specific users added to this project
│ └── Connectors, pipelines, Databasin One, Lakehouse, Gallery
└── Organization-level settings, billing, clusters
A user first exists at the organization level, then gets added to specific projects.
The roles that exist today
Databasin keeps the role list short on purpose.
Organization roles
| Role | Name in the UI |
|---|---|
| Organization admin | Organization Administrator |
| Regular org member | Organization User |
There's also a separate superadmin flag on a user (system-wide). Only other superadmins can toggle it. Superadmin is the "see everything, manage everything" level and is usually reserved for 1–2 people.
Project roles
| Role | Name in the UI |
|---|---|
| Project admin | Project Administrator |
| Regular project member | Project User |
That's it. Two roles per level — a clear "admin or not" split. Fine-grained per-feature roles don't exist today.
Adding someone
To the system (superadmin only)
Admin → All Users → Invite New User. The sidebar label is All Users, it's the system-wide user directory, and only superadmins reach it. From here you create the user and assign organizations.
To an organization
From the org page under Admin, use Add User and pick an existing system user. Assign them Organization Administrator or Organization User.
To a project
From inside a project, use the sidebar's Users shortcut (visible to Project Administrators) and click Add User. Pick from the list of users already in the organization and assign them Project Administrator or Project User.
Shared logins break audit trails, make revocation messy, and prevent per-user scoping. Give each human their own login — it's cheap.
What permissions actually gate
Role names gate Databasin-level actions (who can create a pipeline, who can add a user). But data access is a separate layer:
- Connectors carry their own credentials and scope — the connector's underlying user determines what rows can be read.
- Lakehouse respects catalog-level permissions from the source system (e.g., Postgres user grants).
- Published dashboards re-run SQL under the current viewer's connection, so they only see what that connection allows.
So a Project Administrator who can edit pipelines can't necessarily see every row — if the connector's user only has access to the public schema, that's all anyone in the project sees.
View mode (superadmin only)
Superadmins can switch between a super admin view and an org admin view to see what a regular organization admin would see. It's not full user impersonation — it's a lens over the same account — but it's useful for debugging "why can't they see X?" questions.
The setting lives in the Admin area and persists for the current browser tab. It's part of the wider superadmin console — see System administration for the rest.
SSO and Azure AD
For SaaS-hosted Databasin orgs, login goes through Azure AD / Microsoft Entra ID (via MSAL). New users are provisioned the first time they sign in through your tenant; removing them from AAD removes their Databasin access.
Self-install deployments authenticate through Auth0 instead, which can federate to your own identity provider.
Deleting an organization account
Deleting an org's account is SaaS-only and limited to organization administrators — superadmins can't do it from here. It lives in the org's Settings, behind a Danger Zone confirmation. There's no self-install equivalent.