多くのデータ型が利用できる[16]。

数値型：整数、浮動小数点数、任意の精度を持つ数値、連番

通貨型

文字列：固定長、可変長

可変長バイト列

日時、日付、時刻、時間差分 (タイムゾーンの有無を指定可能)

ブーリアン型

列挙型（8.3以降）

幾何型：点、直線、線分、矩形、閉経路、開経路、多角形、円

ネットワークアドレス：IPv4 / IPv6 アドレス, MAC アドレス

ビット列

テキスト検索に関する型

UUID 型

XML 型

JSON 型：テキスト形式、バイナリ形式

配列型

複合型

範囲型

可変長文字列と可変長バイト列には最大で 1GB を格納できる。一定のサイズを上回るデータ値は TOAST と呼ばれる機能により自動的に圧縮され別領域に配置される。そのため、ページサイズ (通常8KB) を上回るサイズの行であっても保存できる。

さらに、ユーザがデータ型を追加することもでき、それに対してインデックスを作成することもできる。利用例として、GIS 用の型を GiST インデックスで検索可能な PostGIS プロジェクトがある。
ユーザ定義オブジェクト

ユーザはほとんどのデータベース・オブジェクトを追加できる。

データ型 (TYPE) と データの定義域 (DOMAIN)

関数 (FUNCTION) と集約 (AGGREGATE)

演算子 (OPERATOR)

型変換 (CAST)

文字コード変換 (CONVERSION)

手続き言語 (LANGUAGE)

全文検索の設定 (TEXT SEARCH CONFIGURATION)

インデックス・アクセス・メソッド

PostgreSQLが規定する上限

データベースの大きさの上限はない。テーブルのバイト数の最大は32Tbyteである。テーブルの列は1600まで可能だが、運用上の上限はデータ型に依存する。
バキューム

バキューム (VACUUM) とは、追記型アーキテクチャにおける不要領域を回収し、再利用またはOSに返却する処理である。なお、バージョン8.3からはHeap-Only Tuples (HOT) が採用され、インデックスの変更を伴わない更新については、削除された行を直ちに再利用することが可能となり、バキュームの必要な頻度は下がった。

PostgreSQLは、MVCCの実現のため、追記型のアーキテクチャを採用している。データを削除する際は実際のレコードは削除せず、該当行に削除マークを付けるのみである。更新の際も内部的には削除と挿入を同時に行っている。そのため、更新・削除が繰り返されるテーブルにおいては、たとえ理論的な行数が変わらなくとも、更新・運用を重ねるごとに物理的なファイルサイズが増加する。肥大化によるパフォーマンスの劣化を回避するため、次節に述べるバキューム作業を定期的に行う必要がある。

各バージョンによって以下の差異がある。
7.1 以前
データベースファイル内の未使用領域を解放しOSに返却する処理のみをサポートする。このVACUUMでは、処理中のテーブルに対して排他ロックが獲得されるため、VACUUMの間は対象テーブルへのアクセスがブロックされる。システムの規模やテーブルの行数にもよるが、本バージョンにおいてシステムの停止を伴わない運用は困難であった。
7.2
以前の動作を FULL 方式 (VACUUM FULL) とし、新たにコンカレント方式 (VACUUM) が実装された。現在、単にバキュームと言った場合、後者のコンカレントバキュームを指す。コンカレントバキュームでは、テーブルの排他ロックを伴わずに不要領域の回収を行う。不要領域に対して再利用可能フラグを付けるのみの処理となるため、コンカレントバキュームを行っても基本的にデータベースの物理的なサイズは縮小しない。しかし、以降の更新・挿入において、このとき回収した領域が優先的に使用され、更新・削除によるファイルサイズの肥大を防止できる。
7.3
インデックスもコンカレントバキュームの対象になり、肥大化から回復させるための定期的にインデックスを再編成 (REINDEX) する必要が無くなった。これによりデータベース・オブジェクトの排他ロックを要するメンテナンスが不要になり、無停止での運用が可能になった。
7.4
自動的にバキュームを行う contrib/pg_autovacuum モジュールが提供された。autovacuum はシステムを監視し、INSERT/UPDATE/DELETE の回数などの統計情報を利用して、適切なタイミングで適切なテーブルのみに対してバキュームを行う。このため、高度な知識を要すことなく、不要領域の増加を十分に抑えることが可能となった。なお、自動バキューム処理の際に参照される統計情報の記録はデフォルトでオフとなっているため、本機能を利用する際は統計情報の記録オプションもオンにする必要がある。
8.0
バキュームは多くのI/Oが必要なため、負荷の高い処理である。バキューム実行中のシステムの全体の性能悪化を防ぐため、バキュームを行う速度を制限する機能が追加された。ただし、バキューム自体の処理時間はその分多く要する。
8.1
contribより提供されていた自動バキューム (autovacuum) 機能が本体に統合された。不要領域の監視が効率化され、コマンドで発行した VACUUM との連携が可能になった。
8.2
トランザクションIDの周回がテーブル単位で管理されるようになり、定期的にデータベース単位でバキュームを行う必要が無くなった。テーブル単位のバキュームのみが必要である。また複数のバキュームを並列して実行した際の回収効率が向上した。
8.3
自動バキューム機能が標準で有効とされ、複数のテーブルに並列してバキュームを行うようになった。加えて Heap-Only Tuplesの採用により、バキューム自体の必要性が低減した。
8.4
Visibility Map で処理が必要なページを追跡するようになり、バキュームが高速化された。また空き領域のあるページを管理する Free Space Map のメモリ管理が自動化された。
9.0
VACUUM FULL が CLUSTER と類似の処理に変更され、高速化された。
パーティショニング

PostgreSQL 8.1 より、パーティショニングを組み込みでサポートしている。バージョンが上がる度に機能が追加されている。

テーブル・パーティショニングは継承を用いて実現する。これは、Oracle Database 7 のパーティション・ビューに近い実装である。

テーブルを作成する際、他テーブルを「親」テーブルとして指定し、継承関係を定義できる。「子」テーブルに挿入された行は、親テーブルを参照した際にも取得される。親テーブルに対する列の追加やCHECK制約の定義は自動的に子テーブルにも反映されるが、外部キーや一意性制約は継承をサポートしていない。

パーティショニングされたテーブルへは親テーブルを通してアクセスする。SELECT, UPDATE, DELETE 文は子テーブルを含むよう展開されるが、クエリの条件が CHECK 制約に適合しない子テーブルは設定により自動的に除外することもできるため効率よく処理できる。