まず最初に、ディスク上にデータベース格納領域を初期化する必要があります。
この格納領域をデータベースクラスタと呼びます。（標準SQLではカタログクラスタという用語が使用されています）。
データベースクラスタはデータベースの集合で、稼働しているデータベースサーバのただ一つのインスタンスを通して管理されます。
初期化が終わると、データベースクラスタにはpostgresという名前のデータベースが含まれています。
このデータベースは、ユーザ、サードパーティ製アプリケーションがユーティリティで使用するデフォルトデータベースになります。
データベースサーバ自身はこのpostgresデータベースの存在を必要としていません。
初期化中に他にもtemplate1というデータベースが各クラスタ内に作成されます。
その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。
したがって、実際の作業に使用しない方がよいです。
（クラスタ内における新しいデータベースの作成については21章データベース管理を参照してください。）
ファイルシステムの観点から見ると、データベースクラスタというのは、すべてのデータが格納される1つのディレクトリということになります。
これはデータディレクトリもしくはデータ領域と呼ばれます。
どこにデータを格納するかは完全にユーザの自由です。
特にデフォルトの領域はありませんが、一般的によく使われるのは/usr/local/pgsql/dataか/var/lib/pgsql/dataです。
データベースクラスタを初期化するためには、PostgreSQLと一緒にインストールされるコマンドinitdbを使用してください。
データベースクラスタのファイルシステム上の場所は-Dオプションで示します。
例えば次のようにします。
$initdb -D /usr/local/pgsql/data
このコマンドは、前節で説明したPostgreSQLユーザアカウントでログインして実行する必要があります。
他にも以下のようにpg_ctlプログラム経由でinitdbを実行することができます。
$pg_ctl -D /usr/local/pgsql/data initdb
pg_ctlがデータベースサーバインスタンスの管理に使用する単一のコマンドになりますので、サーバの起動や停止にpg_ctlを使用している場合(17.3. データベースサーバの起動参照)はこちらの方がより直感的かもしれません。
もし指定したディレクトリが存在しない場合は、initdbはその新しいディレクトリを作成しようとします。
もちろん、その親ディレクトリに書き込み権限がない場合initdbは失敗します。
PostgreSQLユーザがデータディレクトリだけでなく、親ディレクトリも所有することを一般的に推奨します。
このようにすると問題になることはありません。
目的の親ディレクトリが存在しない場合は、まずそのディレクトリを作成する必要があります。
親の親ディレクトリが書き込み可能でない場合は、root権限を使用して作成します。
そのため、手順は下記のようになります。
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
データディレクトリが存在し、すでにファイルが含まれている場合は、initdbは実行を拒否します。これは、誤って既存のインストールを上書きしないようにするためです。
データディレクトリにはデータベースの中のすべてのデータが保持されるため、権限を持たない人からのアクセスを確実に制限することが不可欠です。
ですから、initdbはPostgreSQLユーザ以外からアクセス権を剥奪します。
しかし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証の設定では、すべてのローカルユーザはデータベースに接続でき、データベーススーパーユーザになることさえ可能です。
他のローカルユーザを信用しない場合、initdbの-W、--pwprompt、--pwfileオプションのいずれか1つを使用して、データベーススーパーユーザにパスワードを付与することを推奨します。
また、デフォルトのtrust認証モードを使用しないように、-A md5もしくは-A passwordを指定してください。
もしくは、initdbの後、初回のサーバの起動の前に、生成済みのpg_hba.confファイルを変更してください。
（他の穏当な方法として、peer認証やファイルシステムの権限を使用して、接続を制限することもできます。
詳細については19章クライアント認証を参照してください。）
initdbはまた、データベースクラスタのデフォルトのロケールを初期化します。
通常は、環境のロケール設定を初期化されたデータベースにそのまま適用します。
データベースに異なるロケールを指定することも可能です。
詳細については22.1. ロケールのサポートを参照してください。
特定のデータベースクラスタ内で使用されるデフォルトのソート順はinitdbで設定されます。
異なるソート順を使用する新しいデータベースを作成することもできますが、initdbが作成するテンプレートデータベースで使用される順は削除して再作成しない限り変更することができません。
また、CやPOSIX以外のロケールを使用する場合には性能上の影響もあります。
ですので初回にこれを正しく選択することが重要です。
またinitdbは、データベースクラスタのデフォルトの文字セット符号化方式も設定します。
通常これは、ロケールの設定と合うものが選ばれなければなりません。
詳細は22.3. 文字セットサポートを参照してください。
非Cおよび非POSIXのロケールでは、文字セットのソート順はオペレーティングシステムの照合ライブラリに依存しています。
これは、インデックスに格納されているキーの順序を制御します。
このためにクラスタは、スナップショットのリストア、バイナリストリーミングレプリケーション、異なるオペレーティングシステム、またはオペレーティングシステムのアップグレードのいずれでも互換性のない照合ライブラリバージョンに切り替えることは出来ません。
多くのインストールは、マシンの「ルート」ボリューム以外のファイルシステム（ボリューム）上でのデータベースクラスタを作成します。 この選択をした場合、データディレクトリをセカンダリボリュームの最上位ディレクトリ（マウントポイント）を使用することはお勧めできません。 最善の方法はマウントポイント内にPostgreSQLユーザが所有するディレクトリを作成することです。 この権限の問題を避けることは、特にpg_upgradeの操作やセカンダリボリュームがオフラインになった時のきれいな失敗になることを保証します。
多くのインストレーションはネットワークファイルシステム上にデータベースクラスタを作成します。 直接NFSを介して行うこともありますし、NFSを内部的に使うネットワークアタッチドストレージ（NAS）デバイスを使用することもあります。 PostgreSQLはNFSファイルシステムに特別なことを何も行いません。 つまりNFSはローカル接続のドライブとまったく同様に振る舞うという前提です。 クライアントとサーバのNFS実装が標準ファイルシステム・セマンティックスを持たないならば、信頼性の問題を引き起こす可能性があります。 （http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html参照）。 具体的には、NFSサーバへの遅延（非同期）書きこみがデータ破損の問題を引き起こす可能性があります。 可能ならばNFSファイルシステムを（キャッシュ無しで）同期マウントし、この危険を防止してください。更に、NFSをソフトマウントすることは薦められません。
ストレージエリアネットワーク（SAN）は通常NFSとは異なる通信プロトコルを使用し、この種の危険がある場合と無い場合があります。 これは、データの整合性の保証に関するベンダのドキュメントを参照することをお勧めします。 PostgreSQLは、使用しているファイルシステム以上に信頼性が高くなることはありません。