Whenever I create a brand new database in PostgreSQL Maestro it creates the following list of default schemas:

enter image description here

Now from my understanding Schemas are like folders for organization, etc. So the question I have is are all these schemas needed when I create a new DB? If so what are they used for on PG side as I won't ever use them myself.

I can understand information_schema as this is default for an install of MySQL on a server, though I don't get why a database would need it's own as opposed to the entire server, but to each DB type his own I guess.


2 Answers 2


What you're seeing is mostly one user interface's way of displaying the structure of a PostgreSQL database.

If you were using pgAdminIII, which is just another administrative interface, each database would usually show two "catalogs": information_schema and pg_catalog. It would also have a schema named "public".

Database objects named "pg_*" are system objects. The pg_toast schema holds TOAST storage for large tables.

The information_schema views are part of the SQL standard. They're supposed to provide a vendor-independent way to determining information that's stored in vendor-specific system tables.

You can make a good case for not exposing every namespace as if it were a user-level schema. (Internally, these are namespaces. Try select * from pg_namespace;.) The only schema in a newly created database that really matters to users is "public".


If you keep the default search_path and use the default schema public (automatically), you don't have to bother with schemas at all.

But if your database grows, chances are you will happily make use of them to organize objects and privileges. By setting the search_path per user / database / session / ... you can manage schemas precedence any way you want. I have assembled a couple of ways to do this in this related answer on SO.

Schemas are much like directories in the file system:
If you don't schema-qualify an object name (myschema.mytable), the first schema in your search_path is assumed when creating objects. That's like the "current directory" in the file system.

All schemas in the search_path are searched in sequence when using objects. Just like with a search path in the file system.

There is no "root schema", and no nesting. You can't store anything "without schema". Every object is created inside a particular schema. (Except special objects on the database-cluster level, like roles and databases.)

The current role needs privileges to access a schema. Schemas are extremely useful if you want to organize things and still be able to access other "areas" in a simple query.

MySQL does not have anything similar. You would use a separate database for many things solved with a separate schema in PostgreSQL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.