CREATE_DATABASE(7)

💖 CREATE DATABASE — the CREATE_DATABASE(7) page, PostgreSQL 18.6 Documentation 💖

okay bestie sit DOWN because we're about to make a whole entire database from scratch and it's gonna be iconic 🎀 this is the CREATE_DATABASE(7) manual page and yes we're doing the whole thing, no skipping, periodt.

---

✨ NAME ✨

CREATE_DATABASE — create a new database 🦋

---

✨ SYNOPSIS ✨

CREATE DATABASE name
    [ WITH ] [ OWNER [=] user_name ]
           [ TEMPLATE [=] template ]
           [ ENCODING [=] encoding ]
           [ STRATEGY [=] strategy ]
           [ LOCALE [=] locale ]
           [ LC_COLLATE [=] lc_collate ]
           [ LC_CTYPE [=] lc_ctype ]
           [ BUILTIN_LOCALE [=] builtin_locale ]
           [ ICU_LOCALE [=] icu_locale ]
           [ ICU_RULES [=] icu_rules ]
           [ LOCALE_PROVIDER [=] locale_provider ]
           [ COLLATION_VERSION = collation_version ]
           [ TABLESPACE [=] tablespace_name ]
           [ ALLOW_CONNECTIONS [=] allowconn ]
           [ CONNECTION LIMIT [=] connlimit ]
           [ IS_TEMPLATE [=] istemplate ]
           [ OID [=] oid ]

look at all those optional little guys. all of them are real, all of them matter, and we're covering every single one 💅

---

✨ DESCRIPTION ✨

CREATE DATABASE creates a new PostgreSQL database. that's it, that's the whole vibe, we're birthing a database 👑

but lowkey there's a gate: to create a database, you must be a superuser or have the special CREATEDB privilege. so like… check your permissions bestie. see CREATE ROLE (CREATE_ROLE(7)) for that.

By default, the new database will be created by cloning the standard system database template1. A different template can be specified by writing TEMPLATE name. In particular, by writing TEMPLATE template0, you can create a pristine database (one where no user-defined objects exist and where the system objects have not been altered) containing only the standard objects predefined by your version of PostgreSQL. This is useful if you wish to avoid copying any installation-local objects that might have been added to template1.

🫶 translation: template1 is the group chat that everyone's already decorated. template0 is a fresh new account with zero posts. sometimes you want the blank one.

---

✨ PARAMETERS ✨

• name — The name of a database to create. give it a name bestie, it deserves one 🌸
• user_name — The role name of the user who will own the new database, or DEFAULT to use the default (namely, the user executing the command). To create a database owned by another role, you must be able to SET ROLE to that role.
• template — The name of the template from which to create the new database, or DEFAULT to use the default template (template1).
• encoding — Character set encoding to use in the new database. Specify a string constant (e.g., 'SQL_ASCII'), or an integer encoding number, or DEFAULT to use the default encoding (namely, the encoding of the template database). The character sets supported by the PostgreSQL server are described in Section 23.3.1. See below for additional restrictions.
• strategy — Strategy to be used in creating the new database. If the WAL_LOG strategy is used, the database will be copied block by block and each block will be separately written to the write-ahead log. This is the most efficient strategy in cases where the template database is small, and therefore it is the default. The older FILE_COPY strategy is also available. This strategy writes a small record to the write-ahead log for each tablespace used by the target database. Each such record represents copying an entire directory to a new location at the filesystem level. While this does reduce the write-ahead log volume substantially, especially if the template database is large, it also forces the system to perform a checkpoint both before and after the creation of the new database. In some situations, this may have a noticeable negative impact on overall system performance. The FILE_COPY strategy is affected by the file_copy_method setting.
• locale — Sets the default collation order and character classification in the new database. Collation affects the sort order applied to strings, e.g., in queries with ORDER BY, as well as the order used in indexes on text columns. Character classification affects the categorization of characters, e.g., lower, upper, and digit. Also sets the associated aspects of the operating system environment, LC_COLLATE and LC_CTYPE. The default is the same setting as the template database. See Section 23.2.2.3.1 and Section 23.2.2.3.2 for details.

Can be overridden by setting lc_collate, lc_ctype, builtin_locale, or icu_locale individually.

If locale_provider is builtin, then locale or builtin_locale must be specified and set to either C, C.UTF-8, or PG_UNICODE_FAST.

💡 Tip The other locale settings lc_messages, lc_monetary, lc_numeric, and lc_time are not fixed per database and are not set by this command. If you want to make them the default for a specific database, you can use ALTER DATABASE ... SET.

• lc_collate — Sets LC_COLLATE in the database server's operating system environment. The default is the setting of locale if specified, otherwise the same setting as the template database. See below for additional restrictions.

If locale_provider is libc, also sets the default collation order to use in the new database, overriding the setting locale.

• lc_ctype — Sets LC_CTYPE in the database server's operating system environment. The default is the setting of locale if specified, otherwise the same setting as the template database. See below for additional restrictions.

If locale_provider is libc, also sets the default character classification to use in the new database, overriding the setting locale.

• builtin_locale — Specifies the builtin provider locale for the database default collation order and character classification, overriding the setting locale. The locale provider must be builtin. The default is the setting of locale if specified; otherwise the same setting as the template database.

The locales available for the builtin provider are C, C.UTF-8 and PG_UNICODE_FAST.

• icu_locale — Specifies the ICU locale (see Section 23.2.2.3.2) for the database default collation order and character classification, overriding the setting locale. The locale provider must be ICU. The default is the setting of locale if specified; otherwise the same setting as the template database.
• icu_rules — Specifies additional collation rules to customize the behavior of the default collation of this database. This is supported for ICU only. See Section 23.2.3.4 for details.
• locale_provider — Specifies the provider to use for the default collation in this database. Possible values are builtin, icu (if the server was built with ICU support) or libc. By default, the provider is the same as that of the template. See Section 23.1.4 for details.
• collation_version — Specifies the collation version string to store with the database. Normally, this should be omitted, which will cause the version to be computed from the actual version of the database collation as provided by the operating system. This option is intended to be used by pg_upgrade for copying the version from an existing installation.

See also ALTER DATABASE (ALTER_DATABASE(7)) for how to handle database collation version mismatches.

• tablespace_name — The name of the tablespace that will be associated with the new database, or DEFAULT to use the template database's tablespace. This tablespace will be the default tablespace used for objects created in this database. See CREATE TABLESPACE (CREATE_TABLESPACE(7)) for more information.
• allowconn — If false then no one can connect to this database 🙈 The default is true, allowing connections (except as restricted by other mechanisms, such as GRANT/REVOKE CONNECT).
• connlimit — How many concurrent connections can be made to this database. -1 (the default) means no limit.
• istemplate — If true, then this database can be cloned by any user with CREATEDB privileges; if false (the default), then only superusers or the owner of the database can clone it.
• oid — The object identifier to be used for the new database. If this parameter is not specified, PostgreSQL will choose a suitable OID automatically. This parameter is primarily intended for internal use by pg_upgrade, and only pg_upgrade can specify a value less than 16384.

---

Optional parameters can be written in any order, not only the order illustrated above. so go off, arrange them however feels right to you, it's giving freedom 💜

---

there's more where this came from, don't go anywhere 🦋

📝 NOTES 📝

Okay bestie, real talk time, the fine print that keeps you out of trouble 💅

• CREATE DATABASE cannot be executed inside a transaction block. Like, it literally cannot, don't even try it, the server will simply say no 🙅‍♀️
• If you're seeing errors that look like “could not initialize database directory”, the vibe is usually one of these: not enough permissions on the data directory, a disk that's completely full 😭, or some other file system shenanigans. It's giving filesystem problem, not SQL problem.
• Wanna yeet a database into the void? That's DROP DATABASE 🗑️
• There's also a whole separate program, createdb(1), which is just a cute little wrapper around this command — provided for convenience, iykyk 🫶
• Heads up: database-level configuration parameters (the ones you'd set via ALTER DATABASE) and database-level permissions (the ones you'd set via GRANT) do NOT get copied over from the template database. Not even a little. So don't assume your new db inherited the drip ✨
• Now this one's important 👀 — yes, you can copy a database other than template1 by passing its name as the template. But it is not (yet) intended to be some general-purpose “COPY DATABASE” facility. The big limitation: no other sessions can be connected to the template database while it's being copied. CREATE DATABASE will flat-out fail if any other connection exists when it starts; and if it doesn't fail, then new connections to the template database are locked out until CREATE DATABASE completes. If you want the full lore, see Section 22.3 📖
• Encoding compatibility check, this is the part people skip and then cry about 😭 The character set encoding you specify for the new database must be compatible with the chosen locale settings (LC_COLLATE and LC_CTYPE). If the locale is C (or equivalently POSIX), then literally all encodings are allowed 🌈 — but for any other locale settings, there is only one encoding that will work properly. (On Windows though, UTF-8 encoding can be used with any locale, so that's cute.) Superusers are allowed by CREATE DATABASE to specify SQL_ASCII encoding regardless of the locale settings, but bestie, that choice is deprecated and may result in misbehavior of character-string functions if you store data that isn't encoding-compatible with the locale in that database. You've been warned 💀
• The encoding and locale settings must match those of the template database — except when template0 is used as the template. Why? Because other databases might contain data that doesn't match the encoding you specified, or might contain indexes whose sort ordering is affected by LC_COLLATE and LC_CTYPE. Copying that data would give you a database that is corrupt according to the new settings 🚨 template0, however, is known to not contain any data or indexes that would be affected, so it's the safe one 🧚
• There's currently no option to use a database locale with nondeterministic comparisons (peep CREATE COLLATION for the explanation). If you need that, you'd have to use per-column collations instead. Not me wishing it existed 🙈
• And the CONNECTION LIMIT option? It's only enforced approximately 👀 If two new sessions start at about the same time when just one connection “slot” remains for the database, it's possible that both will fail. Also, the limit is not enforced against superusers or background worker processes. So, like, it's a vibe, not a guarantee 💅

---

✨ EXAMPLES ✨

Wanna make a new database? Say less:

CREATE DATABASE lusiadas;

Wanna make a database sales owned by user salesapp with a default tablespace of salesspace? Slay:

CREATE DATABASE sales OWNER salesapp TABLESPACE salesspace;

Wanna make a database music with a different locale? Here you go bestie:

CREATE DATABASE music
    LOCALE 'sv_SE.utf8'
    TEMPLATE template0;

In this example, the TEMPLATE template0 clause is required if the locale you specified is different from the one in template1. (And if it's not different, then specifying the locale explicitly is just redundant, no harm but no point either 🤷‍♀️)

Wanna make a database music2 with a different locale and a different character set encoding? Okay main character:

CREATE DATABASE music2
    LOCALE 'sv_SE.iso885915'
    ENCODING LATIN9
    TEMPLATE template0;

The specified locale and encoding settings must match, or an error will be reported. No mismatched vibes allowed 🚫

And ngl, one more thing: locale names are specific to the operating system, so those commands above might not work the same way everywhere. Your mileage may absolutely vary 🌍

---

💫 COMPATIBILITY 💫

There is no CREATE DATABASE statement in the SQL standard. Databases are equivalent to catalogs, whose creation is implementation-defined. So we're off-spec here and honestly? We ate 🍽️

---

👀 SEE ALSO 👀

• ALTER DATABASE (ALTER_DATABASE(7))
• DROP DATABASE (DROP_DATABASE(7))

---

And that's the whole page, bestie 🎀 this was PostgreSQL 18.6, dated 2026, and the page is CREATE DATABASE(7) — go forth and make databases responsibly, mwah 💖✨