【テクニカル・上級編】文字型 (Character Types) – PostgreSQL

PostgreSQLの「文字型」という沼：char, varchar, textを巡る深淵な話

PostgreSQLの設計において、「とりあえず `varchar(255)` にしておけばいいや」という選択をしていませんか？

もしあなたが、DBの設計レビューでそんな設計案を目にしたら、ぜひ一度立ち止まって考えてみてほしいんです。「なぜその型が必要なのか？」を。

今日は、PostgreSQLにおける `char(n)`, `varchar(n)`, `text` という、一見単純そうでいて、実はデータベースの物理設計とパフォーマンスの根幹に関わる深い話をしようと思います。

1. 内部アーキテクチャから見た「違い」の正体

多くのエンジニアが意外に思うかもしれませんが、PostgreSQLの内部では、`varchar(n)` と `text` は完全に同じものとして扱われています。

ソースコードを覗けば一目瞭然ですが、これらはどちらも `varlena` (variable-length) 型であり、内部的にはデータ長のヘッダーを持つ可変長構造体です。`varchar(n)` に指定する `(n)` は、あくまで「挿入時にその長さチェックを行う」という制約（Constraints）に過ぎません。

一方で、`char(n)` は少し事情が異なります。こちらは固定長型であり、指定した長さに満たない場合は末尾にスペースがパディングされます。この「パディング」という挙動が、実はパフォーマンスの微細な落とし穴になることがあるのです。

2. なぜ `char(n)` を避けるべきなのか

かつてのメインフレーム時代や、ストレージが高価だった頃の遺産として `char(n)` が重宝された時代がありました。しかし、現代のPostgreSQLにおいて、安易な `char(n)` の採用は百害あって一利なしです。

無駄なストレージ消費: `char(n)` は、たとえデータが短くても必ず `n` バイト分を確保します。TOAST（The Oversized-Attribute Storage Technique）による圧縮効率も、可変長型に比べれば不自然に悪化します。
比較演算の罠: `char(n)` は比較時に末尾の空白を無視することがあります。これはアプリケーション層との間で予期せぬ不整合を引き起こし、いわゆる「バグの温床」になりがちです。

結論として、DB設計において「固定長であること」を論理的に保証したいのでない限り、`char(n)` を使う理由はほぼありません。

3. パフォーマンスと物理設計の最適解

では、`text` と `varchar(n)` のどちらを選ぶべきか。

パフォーマンスの観点では、両者に物理的な違いはありません。しかし、設計思想の観点からはこう考えます。

`text` を選ぶべきケース: 長さが不定で、特に上限を設ける必要がない場合。シンプルさこそ正義です。
`varchar(n)` を選ぶべきケース: 「メールアドレス」や「郵便番号」のように、ビジネスロジックとして明確な上限がある場合。

ここで重要なのは、「制約はデータベースのドキュメンテーションでもある」という視点です。コードを読んだときに、そのカラムが何を許容しているのかが明示されていること。これだけで、運用フェーズでのデータ不整合のリスクが劇的に減ります。

4. 現場で遭遇する「罠」：パフォーマンストラブルの現場から

私が以前診断した、とある大規模テーブルのクエリ遅延の案件がありました。

原因は、`varchar(255)` に対して、アプリケーション側から「これでもか」というほど長い文字列を突っ込んでいたことでした。PostgreSQLは `varchar(255)` を超えるデータが来た瞬間にエラーを吐きますが、その手前の「境界値付近」で、インデックスのカーディナリティが狂い、クエリプランナーが悲鳴を上げていたのです。

インデックスの肥大化: 長すぎる文字列をインデックスに含めると、B-treeインデックスが肥大化し、メモリ効率が悪化します。
TOASTの発生: 文字列が長くなれば、当然TOASTテーブルへ追い出されます。頻繁にアクセスするカラムがTOASTテーブルに存在すると、I/O負荷が跳ね上がります。

最後に：エンジニアとしての矜持

データベース設計は、単に「動けばいい」というものではありません。

そのカラムが何を表し、どの程度の頻度でアクセスされ、どう変化するのか。それらを見極めた上で、最も適切な型を選択する。その積み重ねが、数年後のデータベースの安定稼働を支える「技術的な負債」にならないための防波堤となります。

「まあ `text` でいいか」という思考停止を捨て、「なぜそのサイズなのか」を突き詰める。そんな小さなこだわりが、世界最高峰のデータベースエンジニアへの第一歩だと、私は信じています。

皆さんの設計が、今日も明日もクリーンであることを願っています。