AccessからPostgreSQLへ移行するには｜向くケースと進め方

結論：PostgreSQLへの移行が向くのは「ライセンス費を抑えたい」「Linux環境に置きたい」ケース

AccessのバックエンドをSQL Serverではなく PostgreSQL に移す選択肢は、費用面と運用環境の2点で検討に値します。PostgreSQLはPostgreSQLライセンス（BSDに近い自由度のオープンソースライセンス）で提供されており、商用利用でもサーバーライセンス費用は発生しません。SQL Server Standard Editionのような購入費・SA費がかかりません。

加えて、PostgreSQLはWindows・Linux・macOS を含む主要OSで動作します（PostgreSQL公式）。社内にLinuxサーバーがある、あるいはクラウドのLinux環境で運用したいという場合、SQL Serverより自然に収まることがあります。

一方で、AccessのフロントエンドをそのままODBC経由でPostgreSQLに接続する構成には、SQL Serverより調整が多く要ります。データ型の違い、日本語エンコーディングの設定、関数名の非互換など、実務で引っかかりやすいポイントがあります。当社の経験上、「SQL Serverの代わりにPostgreSQLを使えば同じことができる」という単純な置き換えではなく、移行前の設計判断が問われる選択です。

SQL Server移行の詳細はAccessの画面はそのまま、データだけSQL Serverへ移す構成に委ねます。この記事ではPostgreSQL固有の論点に絞ります。

SQL Serverと比較して何が違うか

移行先の選択で最もよく対比されるのはSQL Serverです。同じリレーショナルデータベースですが、いくつかの軸で異なります。

SQL Server Expressは無料で使えますが、1データベース10GBの上限があります（SQL Server Expressの制限と手順参照）。PostgreSQLにはエディション制限がなく、Expressの上限を超えるデータ量でも追加費用なく運用できます。

PostgreSQL移行が向くケース・向かないケース

向くかどうかは、既存のAccess環境と社内の技術スタックによります。

当社の経験上、「とにかくライセンス費を出したくない」という理由だけでPostgreSQLを選ぶと、Accessとの接続調整で予想外の工数がかかるケースがあります。移行後にAccessフロントエンドを捨てる計画があるなら、むしろPostgreSQLを選ぶ積極的な理由になります。WebシステムのバックエンドとしてPostgreSQLは広く使われており、AccessをWebシステム化する方向で進む場合は連続性があります。

ODBC接続の設定とデータ型の非互換：実務で引っかかりやすい箇所

AccessフロントエンドをPostgreSQLにODBC経由でリンクテーブル接続する場合、大まかな流れは次のとおりです。

1. PostgreSQL公式ODBCドライバ（psqlODBC）を各PCにインストールする（odbc.postgresql.orgから入手）
2. Windowsの「ODBCデータソース アドミニストレーター」でユーザーDSNを追加し、サーバー名・ポート・データベース名・ユーザー名・パスワードを設定する
3. AccessでリンクテーブルマネージャーからODBCを選択し、PostgreSQLのテーブルをリンクする
4. フォームやレポートがリンクテーブル経由で動くか、1画面ずつ検証する

psqlODBCは「PostgreSQL Unicode」（psqlODBC Unicode版）を使うことが推奨されます。AccessはUnicodeで動作するため、ANSI版ではなくUnicode版を選ぶことで文字化けのリスクを抑えられます。

複数のPCで同じAccess frontendを使う場合は、各PCに同じDSN設定を入れるか、VBAで接続文字列を動的に組み立てる方法をとります。ODBCドライバのバージョンが異なるPCが混在すると挙動が変わることがあるため、バージョンをそろえる運用が望ましいです。

リンクテーブルの維持・再リンクの注意点についてはAccessリンクテーブル運用の注意点も参照してください。

接続が確立できたら、次はデータ型の対応を確認します。

AccessのデータをPostgreSQLに移す際、データ型の対応を事前に整理しておかないと移行後に予期しない動作が出ます。当社の経験上よく問題になる箇所を列挙します。

Access VBAからPostgreSQL関数を呼ぶ場合、関数名の違いが問題になります。例えばAccessのFormat()に相当するものはPostgreSQLではto_char()、DateDiff()はPostgreSQLに直接対応する関数がなく書き直しが必要です。パススルークエリを使うとPostgreSQL側のSQL方言を直接記述できるため、複雑な処理はパススルークエリ経由にまとめる設計が実務上安定しやすいです。

日本語エンコーディングの設定

日本語データを扱う場合、PostgreSQLのデータベース作成時のエンコーディング設定が後から変えにくいため、最初の設計が重要です。

PostgreSQLが日本語向けに利用できるサーバーエンコーディングは UTF8、EUC_JP、EUC_JIS_2004 の3種類です（PostgreSQL公式: Character Set Support 2025年11月時点）。SJIS（Shift JIS）およびSHIFT_JIS_2004はサーバーサイドのエンコーディングとしては設定できません（クライアント側エンコーディングとしての変換は可能）。

既存のAccessファイル（特に.mdb形式）は過去の取り込み経路や運用環境によって、変換できない文字や文字化けのリスクがあります。移行前に実データを実際に変換して検証するステップを入れることが重要です。

実務上の推奨は、PostgreSQLのデータベースをUTF8で作成し、psqlODBCのUnicode版ドライバを使ってAccessと接続する構成です。移行前にデータをCSVエクスポートしてエンコーディングを確認するステップを入れると、後からの問題発見を防げます。当社の経験上、日本語の人名・地名に環境依存文字（JIS X 0213外の字）が含まれているデータでの文字化けは見落としやすい箇所です。

現状のAccessファイルにどのような文字が含まれているか確認したい場合は、無料の解析可否チェックで状況を把握するところから始めると整理しやすいです。

移行手順の概要

AccessからPostgreSQLへのデータ移行は、大きく3つの方法があります。

一つ目はCSV経由の手動移行です。AccessからCSVをエクスポートし、PostgreSQLのCOPYコマンドまたはpgAdminのインポート機能でデータを取り込みます。シンプルで制御しやすく、小〜中規模のテーブル数であれば手堅い方法です。テーブルのDDL（CREATE TABLE文）は別途PostgreSQL向けに書き起こす必要があります。

二つ目はMDB Toolsを使う方法です。Linux環境で動くオープンソースツールで、AccessのmdbファイルをTSV/CSVに変換してPostgreSQLに取り込む流れです。フリーですが、テーブル名や列名にスペースが含まれていると追加の対処が必要です。

三つ目はサードパーティのGUIツールです。ESF Database Migration ToolkitやFull Convertなど有償ツールは、スキーマの変換からデータの移行まで半自動でこなせます。テーブル数が多い場合や作業を内製しにくい場合に選択肢になります。

いずれの方法でも、Accessから更新・削除するテーブルには主キーまたは適切な一意インデックスを用意しておく必要があります。行を一意に識別できないテーブルはODBC経由での更新・削除操作で問題が出ます（SQL Server移行の同様の注意点も参照）。

移行全体のコスト感についてはAccess移行の費用相場を参考にしてください。PostgreSQL移行の費用はSQL Server移行と同水準になることが多いですが、構成の複雑さとVBA改修の量次第です。

よくある質問

Q. PostgreSQLは本当に無料ですか。商用利用でもライセンス費は発生しませんか。

PostgreSQL本体はPostgreSQLライセンス（オープンソース）で提供されており、商用利用でもサーバーライセンス費用は発生しません（PostgreSQL公式ライセンスページ）。ただし、商用サポートが必要な場合はEnterpriseDB等のベンダーサポートを別途契約するケースがあり、その費用は別です。クラウドのマネージドサービス（AWS RDS、Azure Database for PostgreSQL等）を使う場合もインフラ費用が発生します。

Q. AccessのVBAコードはPostgreSQL移行後もそのまま動きますか。

リンクテーブル経由でPostgreSQLに接続した場合、Accessフォームの基本的な操作（レコードの表示・追加・編集・削除）は動くことが多いです。ただし、T-SQLの構文を直接書いたパススルークエリや、SQL Server固有の関数を呼んでいるVBAコードは書き直しが必要です。当社の経験上、VBAからSQL文を動的に組み立てている箇所は特に確認が要ります。AccessのDAOを使ってローカルテーブルに直接書いていたコードは、リンクテーブルに付け替えるだけで動き続けることもあります。

Q. PostgreSQLとSQL Server、どちらが移行しやすいですか。

AccessフロントエンドをそのままODBC接続で使い続ける前提なら、当社の経験上はSQL Serverの方が移行の障壁が低いです。Microsoftが公式の移行ガイドとSSMAを整備しており、ODBC接続の情報も豊富です。PostgreSQLは移行後にAccessフロントエンドを使わない構成、つまりWebシステムへの移行を見据えている場合に選ぶ積極的な理由になります。移行先の比較についてはAccessの移行先比較も参考にしてください。

Q. Accessの日付データがPostgreSQLに移行後に1900年になったりしますか。

AccessとPostgreSQLで日付の基準日（シリアル値の起点）が異なるため、変換ツールを使わず数値として取り出した場合はズレが生じることがあります。CSV経由でテキストとして日付を扱う場合は問題が出にくいですが、VBAでDate型の変数を整数値に変換してから移行するような手順では注意が必要です。移行前に日付カラムのサンプルデータを実際に変換してみることを当社では推奨しています。