データベースの「器」を作るということ：PostgreSQLにおけるCREATE/DROP DATABASEの深淵
PostgreSQLを触り始めて最初に覚えるコマンドといえば、間違いなく `CREATE DATABASE` でしょう。しかし、熟練のエンジニアである皆さんが、単に「箱を作って終わり」にしているとしたら、それは少しもったいない。
今回は、あえて基本中の基本であるデータベースの作成と削除を、少しだけ「裏側」の視点から掘り下げてみたいと思います。運用現場で「なぜあそこで詰まったのか」「なぜあの設定が必要だったのか」という疑問の答えは、意外とこのあたりに転がっていたりするものです。
—
1. CREATE DATABASEの裏側：テンプレートという名の「原型」
`CREATE DATABASE` を実行するとき、皆さんは `TEMPLATE` オプションを意識していますか？
デフォルトでは `template1` が使われますが、これは単なるデフォルト値ではありません。PostgreSQLは新しいデータベースを作成する際、テンプレートとなるデータベースの物理ファイルをコピー（実際にはOSレベルでのファイルコピー）して新しい「器」を作ります。
- 知っておくべき罠: `template1` に余計な拡張機能や巨大なテーブルを置いてはいけません。なぜなら、次に誰かが `CREATE DATABASE` を実行するたび、それらが全てコピーされるからです。
- 現場のベストプラクティス: 本番環境で頻繁にDBを動的に生成するようなアーキテクチャ（マルチテナント型など）を採用している場合、専用の「マスターテンプレートDB」を作成し、そこに `pg_extension` や必要なスキーマ構造を事前インストールしておくのが鉄則です。これにより、DB作成時のオーバーヘッドを劇的に抑えられます。
2. 「所有者」と「接続」の複雑な関係
`OWNER` 句を省略するとコマンドを実行したユーザーが所有者になりますが、これは運用中、しばしば悪夢を招きます。
特に注意したいのが、「データベースを削除したいのに削除できない」という事態です。これの原因の9割は、他のユーザーがそのデータベースに接続していること（アクティブなセッションがあること）です。
— 削除できない時の定石
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = ‘target_db’ AND pid <> pg_backend_pid();
現場ではよくこのスニペットのお世話になりますが、これを実行する前に「なぜ接続が切れないのか」を考えるのがプロの仕事です。コネクションプール（PgBouncerなど）が生き残っていないか、あるいはバックグラウンドジョブがゾンビのように残っていないか。`DROP DATABASE` が失敗する原因は、多くの場合アプリケーション側の設計に起因します。
3. 物理削除の重み：DROP DATABASEとチェックポイント
`DROP DATABASE` は、単にカタログから名前を消すだけではありません。データディレクトリ内の関連する物理ファイルをすべて削除（unlink）します。
ここで注意が必要なのが、大量のデータを持つデータベースを削除する際の I/Oスパイク です。
- パフォーマンストラブルの種: 何TBもある巨大なデータベースを一気に `DROP` すると、OSのファイルシステムレベルで大量のファイル削除処理が発生し、ディスクI/Oが飽和します。最悪の場合、共有ストレージや他のデータベースのクエリが巻き添えを食らい、レイテンシが急上昇します。
- 回避策: 巨大なDBを破棄する際は、いきなり `DROP` するのではなく、事前に不要な大きなテーブルを `TRUNCATE` しておくか、`pg_dropdb` のようなツールを活用して、負荷を分散させながら削除する計画性が求められます。
4. 最後に：データベースは「箱」以上の存在である
新人エンジニアにとっての `CREATE DATABASE` は「始まり」ですが、ベテランにとってのそれは「設計の表明」です。
どこのテーブルスペースに配置するか、どんなロケール設定（LC_COLLATE / LC_CTYPE）で初期化するか。これらは後から変更するのが非常に困難な、データベースの「骨格」です。
特にロケールの選択は、インデックスのソート順や文字列検索のパフォーマンスに直結します。ここを安易にデフォルト（システム依存）にせず、ビジネス要件に合わせて明示的に指定できるエンジニアこそが、真にPostgreSQLを使いこなしていると言えるのではないでしょうか。
データベースを作る、消す。この何気ない操作一つひとつに、皆さんのエンジニアリングの哲学が宿ります。次に `CREATE` を叩くとき、少しだけその裏側の物理的な挙動を想像してみてください。きっと、これまでとは違う景色が見えてくるはずです。
それでは、良いデータライフを！
コメント