PlanetScale Organizations let you group related databases and manage access for your team members.
Let’s see it in action. Imagine you’re building a new SaaS product. You’ll likely have a main application database, maybe a separate one for analytics, and perhaps a staging environment. Instead of managing these as disparate entities, you can bring them under a PlanetScale Organization.
Here’s a quick look at how it might appear in the PlanetScale UI.
[Image: A screenshot of the PlanetScale dashboard showing a list of organizations, with one organization expanded to show a list of databases within it.]
This organization, let’s call it "AcmeCorp," contains three databases: acmecorp-app-prod, acmecorp-analytics-prod, and acmecorp-app-staging.
The core problem PlanetScale Organizations solve is centralized control and access management for multiple databases. Without organizations, you’d be adding individual team members to each database, which quickly becomes unmanageable and error-prone as your team and database count grow.
Internally, an organization acts as a container. When you invite a user to an organization, you can grant them specific roles that apply across all databases within that organization, or even to specific databases. The common roles are:
- Owner: Full control over the organization and all its resources.
- Developer: Can create, manage, and delete databases within the organization, and manage schema.
- Read-only: Can view database schemas and data but cannot make changes.
You can also define custom roles with granular permissions.
Let’s say you have a new junior developer, Alice, joining your team. You want her to be able to work on the staging database and contribute to the production analytics database, but not touch the main production application database.
You’d invite Alice to the AcmeCorp organization. Then, you’d grant her the Developer role on the acmecorp-app-staging and acmecorp-analytics-prod databases. For the acmecorp-app-prod database, you might assign her a Read-only role, or perhaps no role at all if you want to restrict her access entirely.
The CREATE DATABASE command, when run within an organization, automatically associates the new database with that organization.
CREATE DATABASE acmecorp-new-feature-dev;
This command, when executed by a user with appropriate permissions within the AcmeCorp organization, will create acmecorp-new-feature-dev as a database within AcmeCorp.
The true power comes when you start thinking about team workflows. You can create a DevOps team and grant them Owner access to the entire organization. Then, create a Frontend team and grant them Developer access only to the acmecorp-app-prod and acmecorp-app-staging databases. This ensures that only the designated team can manage critical production databases, while others have the necessary access for their responsibilities.
When you’re managing billing, it’s all consolidated at the organization level. You’ll have a single invoice for all databases within an organization, simplifying financial tracking. This also means that usage limits and quotas are applied at the organization level by default, though some resources might have per-database limits as well.
A common point of confusion is how branch access works within an organization. While an organization groups databases, access to specific database branches is managed independently. A user might have Developer access to the acmecorp-app-prod database (meaning they can create branches), but they still need to be granted permission to deploy changes from a specific branch to another, or to merge branches. This is handled through the UI or planetscale CLI commands that target specific branches.
The next concept you’ll encounter is PlanetScale’s branching and deployment workflows, which are tightly integrated with organization and team management.