PlanetScale’s permissions model is actually a bit more like a bouncer at a VIP club than a traditional role-based access control system, and that’s where the magic (and confusion) lies.
Let’s see it in action. Imagine you’ve got a database named my-cool-db in your PlanetScale organization. You want to grant your teammate, Alex, access to it.
First, Alex needs to be part of your PlanetScale organization. If they aren’t, you’d invite them through the organization’s settings.
Then, you navigate to your my-cool-db database, go to its "Settings" tab, and then select "Access". Here, you’ll see a list of people who have access. You click "Add Person" and type in Alex’s email address.
Now, this is where it gets interesting. You don’t just add Alex; you grant them a specific role on that database. The available roles are: "Admin", "Developer", and "Read-only".
- Admin: Can do anything: manage schema, deploy branches, invite/remove users, and even delete the database.
- Developer: Can manage schema, deploy branches, and view data. They can’t manage users or delete the database.
- Read-only: Can only view schema and data.
So, if you grant Alex "Developer" access, they can work on branches, make schema changes, and see the data. If you only wanted them to be able to query the database, you’d select "Read-only".
The mental model to build is this: your organization is the overarching container. Within that, databases are individual resources. Permissions are attached directly to the database resource and define what a specific member of the organization can do with that specific database. It’s not about global roles that then get applied to databases; it’s about assigning a database-specific capability to a person who is already in your organization.
This direct-to-resource assignment is why you don’t see complex role hierarchies or permission inheritance in the traditional sense. Each database is a distinct security boundary, and you explicitly define who can do what with it. The "bouncer" metaphor holds: Alex gets past the club (the database) door, but only with the wristband (the role) that dictates what areas they can access inside.
What most people miss is that the "Admin" role on a database is also how you remove someone’s access entirely. If you want to revoke Alex’s access to my-cool-db, you’d go back to the "Access" settings for that database and click the "Remove" button next to their name. This is because "Admin" is the only role that can manage other users’ access to that specific database.
The next step is to understand how these database-level permissions interact with branch-specific permissions, which offer even finer-grained control.