Working as a team
Least-privilege access for your team, sharing SQL and settings, reviewing changes, and what is recorded.
Everyone on the team works in the same projects, with access set by their role (Organizations, members and roles). A few habits keep that safe as the team grows.
Give people only what they need
| Person | Role | Why |
|---|---|---|
| Founders, tech leads | Owner (at least two) | Someone must always be able to manage billing and members. |
| Team leads, ops | Admin | Manage members, keys and settings without owning the account. |
| Developers | Member | Build and deploy, without billing, keys or project settings. |
| Support, analysts, auditors | Viewer, or a custom role with database.read and logs.read | See data and logs, change nothing. |
| Contractors on one project | A custom role assigned to that project only | Nothing in your other projects. |
Share work
- SQL editor: save a query under Shared with team so everyone sees it; Private queries are yours (Database).
- Policies, functions, schema: every change is versioned with who made it (Version history: see, undo and restore changes).
- Staging: try changes in an environment before production (Environments, staging and deploying to production).
- Simulation: attach a simulation run to a change so reviewers see who it lets in or out (Simulate access before you ship).
What is recorded
Sign-ins, member and role changes, key and secret changes, policy changes, deploys, migrations and settings changes are recorded with who, when and from where — Audit log.
Checklist
- At least two owners; two-factor authentication on for everyone.
- Developers are Members, not Admins.
- The service role key lives in a secret store, not in a repository or a laptop's
.env. - CI uses its own custom key or token, not a person's.
- When someone leaves: remove them, rotate keys they could read, review the audit log.
Something unclear or missing on this page?Tell us