En fait, CREATE DATABASE fonctionne en copiant une base de données préexistante. Par défaut, cette commande copie la base de données système standard template1. Ainsi, cette base de données est le « modèle » à partir duquel de nouvelles bases de données sont créées. Si vous ajoutez des objets à template1, ces objets seront copiés dans les bases de données utilisateur créées ultérieurement. Ce comportement permet d'apporter des modifications locales au jeu standard d'objets des bases de données. Par exemple, si vous installez le langage de procédures PL/Perl dans template1, celui-ci sera automatiquement disponible dans les bases de données utilisateur sans qu'il soit nécessaire de faire quelque chose de spécial au moment où ces bases de données sont créées.

Néanmoins, CREATE DATABASE ne copie pas les droits GRANT au niveau base de données, attachés à la base source. La nouvelle base de données a les droits par défaut au niveau base.

Il y a une seconde base de données système standard appelée template0. Cette base de données contient les mêmes données que le contenu initial de template1, c'est-à-dire seulement les objets standards prédéfinis dans votre version de PostgreSQL. template0 ne devrait jamais être modifiée après que le cluster des bases de données ait été créé. En indiquant à CREATE DATABASE de copier template0 au lieu de template1, vous pouvez créer une base de données utilisateur « vierge » (une base où aucun objet défini par un utilisateur n'existe et où les objets systèmes n'ont pas été modifiés) qui ne contient aucun des ajouts locaux à template1. Ceci est particulièrement pratique quand on restaure une sauvegarde réalisé avec pg_dump : le script de dump devrait être restauré dans une base de données vierge pour être sûr de recréer le contenu correct de la base de données sauvegardée, sans survenue de conflits avec des objets qui auraient été ajoutés à template1.

Une autre raison habituelle de copier template0 au lieu de template1 est que les nouvelles options d'encodage et de locale peuvent être indiquées lors de la copie de template0, alors qu'une copie de template1 doit utiliser les mêmes options. Ceci est dû au fait que template1 pourrait contenir des données spécifiques à l'encodage ou à la locale alors que template0 n'est pas modifiable.

Pour créer une base de données à partir de template0, on écrit :

CREATE DATABASE nom_base TEMPLATE template0;

dans l'environnement SQL ou

createdb -T template0 nom_base

dans le shell.

Il est possible de créer des bases de données modèles supplémentaires et, à vrai dire, on peut copier n'importe quelle base de données d'un cluster en la désignant comme modèle pour la commande CREATE DATABASE. Cependant, il importe de comprendre, que ceci n'est pas (encore) à prendre comme une commande « COPY DATABASE » de portée générale. La principale limitation est qu'aucune autre session ne peut être connectée à la base source tant qu'elle est copiée. CREATE DATABASE échouera si une autre connexion existe à son lancement. Lors de l'opération de copie, les nouvelles connexions à la base source sont empêchées.

Deux drapeaux utiles existent dans pg_database pour chaque base de données : les colonnes datistemplate et datallowconn. datistemplate peut être positionné à vrai pour indiquer qu'une base de données a vocation à servir de modèle à CREATE DATABASE. Si ce drapeau est positionné à vrai, la base de données peut être clonée par tout utilisateur ayant le droit CREATEDB ; s'il est positionné à faux, seuls les superutilisateurs et le propriétaire de la base de données peuvent la cloner. Si datallowconn est positionné à faux, alors aucune nouvelle connexion à cette base de données n'est autorisée (mais les sessions existantes ne sont pas terminées simplement en positionnant ce drapeau à faux). La base de données template0 est normalement marquée datallowconn = false pour empêcher qu'elle ne soit modifiée. Aussi bien template0 que template1 devraient toujours être marquées datistemplate = true.