PostgreSQL "Permission Denied for Schema public" (15 and Later): Why GRANT ALL ON DATABASE Doesn't Fix It, and the Three Fixes That Do

"ERROR: permission denied for schema public" on CREATE TABLE means you're on PostgreSQL 15 or later, where ordinary users can no longer create objects in the public schema by default. The fix is one statement, run by the database's owner: GRANT CREATE ON SCHEMA public TO app;, with your application's user in place of app. Two other fixes work too: make the application's user the owner of the database, or give it a schema of its own. Here's what wastes most people's afternoon: the fix everyone tries first, GRANT ALL PRIVILEGES ON DATABASE, doesn't help at all, because database privileges don't include the schemas inside it. And if the wrong user runs the right GRANT, PostgreSQL prints "WARNING: no privileges were granted", then reports GRANT as if it worked. This page shows what changed in PostgreSQL 15, each fix with who can run it, the follow-up "permission denied for table" for other users, and the setup to use on Amazon RDS.

Ethan, a developer, gave the booking app for his friend Jake's phone repair shop a new PostgreSQL 17 database on Amazon RDS, with its own database user, as good practice says. The app's first migration failed on its first table. Ethan granted the user "all privileges" on the database. It failed again, with exactly the same message.

New to these terms? In PostgreSQL, a database holds schemas, which hold tables. Every new database has one schema, public, which is where tables go unless you say otherwise. Amazon RDS runs PostgreSQL for you, with the same rules.

What changed in PostgreSQL 15

Here's Ethan's first migration, as the app's user on PostgreSQL 17:

CREATE TABLE repairs (id serial PRIMARY KEY, device text);

ERROR:  permission denied for schema public
LINE 1: CREATE TABLE repairs (id serial PRIMARY KEY, device text);
                     ^

The same statement, by the same kind of user, works on PostgreSQL 14. Until version 14, every user could create objects in public. Starting with PostgreSQL 15, that right was removed, and the public schema now belongs to a special role, pg_database_owner, which means "whoever owns this database":

The change closes a security hole: on shared databases, any user could create objects that other users' queries might pick up by accident. The cost lands on you: every application user you create now needs to be given somewhere to create its tables, on purpose.

Jake: "So the database stopped letting strangers put things in the lobby?"

Ethan: "And our app is a stranger until someone hands it a key. I'd been handing it keys to the wrong door."

Why GRANT ALL ON DATABASE doesn't fix it

The first thing almost everyone tries:

GRANT ALL PRIVILEGES ON DATABASE shopapp TO app;

It runs without complaint, and the next CREATE TABLE fails exactly as before. Privileges on a database cover only database-level actions: connecting, creating new schemas, and creating temporary tables. They say nothing about the schemas inside it. Creating a table in public needs the CREATE privilege on the schema, which is a separate grant.

When you hit this error, work through it in order:

1. Check your server version with SHOW server_version;. On 15 or later, this behavior is expected.
2. Connect to the database your app uses, not the default postgres database.
3. Check whether your app's user can create there: SELECT has_schema_privilege('app', 'public', 'CREATE'); returns f when it can't.
4. Find the database's owner with the query in the next section, and connect as that user.
5. Apply one of the three fixes below, then run the has_schema_privilege check again; it should say t.

Fix 1: grant CREATE on the public schema

Connected to the right database, as its owner, grant the schema privilege:

GRANT CREATE ON SCHEMA public TO app;

Then your app's CREATE TABLE works. Two details matter. You must be connected to the database in question, because each database has its own public schema; in psql, that's \c shopapp first. And you must run the GRANT as the database's owner, or as a superuser. On Amazon RDS, the master user isn't a real superuser, but if it created the database, it owns it, so it can run this grant.

"WARNING: no privileges were granted": the GRANT that does nothing

Run the same GRANT as a user who doesn't own the database, and PostgreSQL answers like this:

WARNING:  no privileges were granted for "public"
GRANT

The command finishes with GRANT, the same word a successful grant prints, so if your script only checks for errors, it treats this as success. Nothing changed. Check who owns the schema and the database:

SELECT nspname, pg_get_userbyid(nspowner) FROM pg_namespace WHERE nspname = 'public';
SELECT datname, pg_get_userbyid(datdba) FROM pg_database WHERE datname = current_database();

On PostgreSQL 15 and later, the first query shows pg_database_owner, and the second tells you which user that is for your database. Connect as that user and run your GRANT again.

Jake: "It said GRANT, but it didn't grant anything?"

Ethan: "It said it in small print, in a warning above. The word GRANT just means the command finished."

Fix 2: make the application's user the database owner

If your database exists only for one application, the simplest arrangement is to make your application's user its owner. The owner is pg_database_owner for that database, so it can create in public without any grant:

ALTER DATABASE shopapp OWNER TO app;

A superuser can run that as it is. A user who isn't a superuser, such as the master user on Amazon RDS, meets one more rule on PostgreSQL 16 and later: it must be able to act as the new owner, or the command fails:

ERROR:  must be able to SET ROLE "app"

Grant yourself membership in the app's role first; a user that can create roles can do that for roles it created. Then create the database with the right owner from the start, which is the cleanest version:

GRANT app TO CURRENT_USER;
CREATE DATABASE shopapp OWNER app;

The trade-off: the application's user now owns everything in the database, including the right to drop it, so this fits single-application databases better than shared ones.

Fix 3: give the application a schema of its own

If you share one database between several applications, the tidiest fix is a schema named after your application's user, owned by it:

CREATE SCHEMA app AUTHORIZATION app;

You don't need to change your application. PostgreSQL's default search path is "$user", public: it looks for a schema with the user's own name first. So the app's unchanged CREATE TABLE repairs now lands in the app schema:

 schemaname | tablename
------------+-----------
 app        | repairs
(1 row)

Each application gets its own space, and nobody needs CREATE on public. Here's how the three fixes compare:

The next error: other users and "permission denied for table"

Once the app creates its tables, a second user, such as a reporting account, hits the next wall:

ERROR:  permission denied for table repairs

Tables belong to the user who created them, and other users need explicit grants. As the app's user, grant read access to everything that exists, and set default privileges so tables created later are covered too:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporter;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO reporter;

Without the second line, the reporting user can read today's tables and gets "permission denied" again on the first table the app adds next month. Default privileges apply to tables created by the user who ran the ALTER DEFAULT PRIVILEGES, which is why the app's own user should run it.

Setting up an application database on RDS

On Amazon RDS for PostgreSQL 15 and later, this is the order that avoids every error on this page:

1. Connect as the master user and create the application's user: CREATE ROLE app LOGIN PASSWORD '...';.
2. Give the master user membership in that role with GRANT app TO CURRENT_USER;, then create the database owned by it: CREATE DATABASE shopapp OWNER app;. Or, for a shared database, create it as the master user and run CREATE SCHEMA app AUTHORIZATION app; inside it.
3. Create any read-only users, and have the app's user grant them SELECT plus default privileges.
4. Store each user's password in Secrets Manager, not in the application's code.
5. Run the app's migrations once by hand and read the output for any WARNING lines, not just errors.

Migration tools in every framework run plain CREATE TABLE statements as the app's user, so the same fixes apply whatever you use. If the app can't reach the database at all, our RDS connection guide covers the network side.

Troubleshooting by symptom

ERROR: permission denied for schema public

PostgreSQL 15 or later. As the database owner, run GRANT CREATE ON SCHEMA public TO your app's user.

GRANT ALL ON DATABASE didn't help

Database privileges don't cover schemas. Grant CREATE on the schema instead.

WARNING: no privileges were granted for "public"

You're not the database owner. Find the owner with pg_database, connect as that user, and grant again.

The GRANT worked, but CREATE TABLE still fails

You granted in a different database. Connect to the app's database first; each has its own public schema.

ERROR: must be able to SET ROLE

On PostgreSQL 16 and later, a non-superuser must be a member of the new owner's role. Run GRANT app TO CURRENT_USER first.

ERROR: permission denied for table

Another user created the table. Have that user grant SELECT, plus ALTER DEFAULT PRIVILEGES for future tables.

It worked on PostgreSQL 14 but not after upgrading

Databases upgraded from 14 keep their old public schema settings; new ones on 15 and later don't. Grant explicitly.

PostgreSQL permission denied for schema public: frequently asked questions

Ethan dropped the half-created database, gave his master user membership in the app's role, and made the database again with CREATE DATABASE shopapp OWNER app;. The migration ran clean, and the reporting user got SELECT plus default privileges in the same session. Jake asked why the "all privileges" grant hadn't worked. "All the privileges of the building," Ethan said, "none of the rooms."

Revision note. Written October 13, 2026, for PostgreSQL 15 to 18, including Amazon RDS for PostgreSQL. "Good fences make good neighbors," goes the old saying; PostgreSQL 15 built the fence, and every app now needs a gate of its own.