A small number of objects, like role, database, and tablespace names, are defined at the cluster level and stored in the
pg_global tablespace. Inside the cluster are multiple databases, which are isolated from each other but can access cluster-level objects. Inside each database are multiple schemas, which contain objects like tables and functions. So the full hierarchy is: cluster, database, schema, table (or some other kind of object, such as a function).
When connecting to the database server, a client must specify in its connection request the name of the database it wants to connect to. It is not possible to access more than one database per connection. However, an application is not restricted in the number of connections it opens to the same or other databases. Databases are physically separated and access control is managed at the connection level. If one Postgres Pro server instance is to house projects or users that should be separate and for the most part unaware of each other, it is therefore recommended to put them into separate databases. If the projects or users are interrelated and should be able to use each other's resources, they should be put in the same database but possibly into separate schemas. Schemas are a purely logical structure and who can access what is managed by the privilege system. More information about managing schemas is in Section 5.8.
Databases are created with the
CREATE DATABASE command (see Section 22.2) and destroyed with the
DROP DATABASE command (see Section 22.5). To determine the set of existing databases, examine the
pg_database system catalog, for example
SELECT datname FROM pg_database;
The psql program's
\l meta-command and
-l command-line option are also useful for listing the existing databases.
The SQL standard calls databases “catalogs”, but there is no difference in practice.