One Postgres cluster, many apps — PlanetScale📹 The future of AI infrastructure: optimize and shard your database with agents.Watch the talk
Navigation<br>Blog|Engineering<br>Table of contents «Close »Table of contents<br>The goal<br>Definitions<br>About logical databases<br>Creating logical databasesRevoke logical database permissions<br>About roles<br>Creating roles<br>Grant permissions<br>Speeding up the process
Automating logical database and role pairsPrepare your database cluster<br>Create a service token<br>Initialize Pulumi<br>Configure the stack<br>Build the program<br>Test and deploy<br>Per-database connections<br>Packing the car
Schema and migrations<br>Conclusion<br>PlanetScale Postgres is the fastest way to run Postgres in the cloud. Plans start at just $5 per month.<br>Learn more
Get the RSS feed
One Postgres cluster, many apps<br>Simeon Griggs [@simeonGriggs] | June 25, 2026<br>Yo, I heard you liked databases, so we put logical databases in your database cluster so you can database while you database
The goal<br>Say we want to run multiple applications with distinct schemas. Let's start with two classic side project app ideas: a blog and a to-do list.<br>PlanetScale Postgres clusters start at $5/month, but this doesn't mean you have to create a new one for every new app idea. A single database cluster can contain many logical databases.<br>However, orchestrating logical databases and the roles that connect to them gets complicated fast. We can automate away the complexity, but let's first understand how they work.<br>Note<br>Running multiple small applications from a single database cluster is great for spikes and side projects. When you need to scale an application to thousands of users, it's best to use dedicated Postgres clusters.
Definitions<br>Database cluster: The shared Postgres instance (compute, storage, connection endpoint) of a single branch. Apps connect to the cluster via a connection string.<br>Branch: An isolated Postgres environment inside that cluster (e.g. main). Connection credentials are scoped to a branch. Role usernames include the branch's ID (e.g. .).<br>Logical database: A named Postgres database within a cluster (e.g. blog, todo) with its own schema and data. Logical databases share the branch's compute, storage, and connection limits.<br>Role: A unit of access control: a username, password, and permissions.<br>About logical databases<br>A new managed Postgres instance likely already contains a few logical databases, primarily for administration. In a fresh PlanetScale Postgres database, you may see multiple logical databases owned by pscale_admin and pscale_superuser.<br>If you're using pgcli, you can list all logical databases with \l, the output should look something like this:<br>pg> \l
+------------------+------------------+----------+-------------+-------------+---------------------------------------+<br>| Name | Owner | Encoding | Collate | Ctype | Access privileges |<br>|------------------+------------------+----------+-------------+-------------+---------------------------------------|<br>| postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres=CTc/postgres |<br>| | | | | | pscale_api_ecr2xwwa8rhj=c/postgres |<br>| pscale_admin | pscale_admin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/pscale_admin |<br>| | | | | | pscale_admin=CTc/pscale_admin |<br>| pscale_exporter | pscale_admin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/pscale_admin |<br>| | | | | | pscale_admin=CTc/pscale_admin |<br>| | | | | | pscale_exporter=c/pscale_admin |<br>| pscale_pgbouncer | pscale_admin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | |<br>| template0 | pscale_admin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/pscale_admin |<br>| | | | | | pscale_admin=CTc/pscale_admin |<br>| template1 | pscale_superuser | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/pscale_superuser |<br>| | | | | | pscale_superuser=CTc/pscale_superuser |<br>+------------------+------------------+----------+-------------+-------------+---------------------------------------+
These other logical databases can be safely ignored. Typically, you'll only interact with the postgres database, which has the postgres owner.<br>Creating more logical databases in a cluster is straightforward, but the permission structure of Postgres makes isolating access to them a little difficult.<br>Creating logical databases<br>You will need to connect to and work "inside" the database cluster to create logical databases. It is not done at the platform level.<br>After creating a new database cluster in the PlanetScale dashboard, you'll need to create a role to connect to it. The "default role" has full privileges and is ideal for the following steps.
While connected with a role with the postgres permissions, create the logical databases.<br>CREATE DATABASE blog;<br>CREATE DATABASE todo;
Revoke logical database permissions<br>By default, any current and future role can CONNECT to new logical databases. If we want the blog and todo logical databases to be isolated from one another, we'll need to revoke these permissions.<br>In Postgres, PUBLIC is a special keyword that represents every existing and future role...