メモリ内でのみPostgreSQLを実行する

（インメモリPostgreSQLの使用と一般化から私の答えを移動します）：

Pgをインプロセス、インメモリで実行することはできません

テストのためにメモリ内のPostgresデータベースを実行する方法がわかりません。可能ですか？

いいえ、できません。 PostgreSQLはCで実装され、プラットフォームコードにコンパイルされます。 H2やDerbyとは異なり、 jarをロードするだけでは不十分です。使い捨てのインメモリDBとして起動します。

これもCで記述され、プラットフォームコードにコンパイルされるSQLiteとは異なり、PostgreSQLはインプロセスでロードすることもできません。マルチスレッドアーキテクチャではなくマルチプロセッシングであるため、複数のプロセス（接続ごとに1つ）が必要です。マルチプロセッシング要件は、必須であることを意味しますポストマスターをスタンドアロンプロセスとして起動します。

代わりに：接続を事前設定します

特定のホスト名/ユーザー名/パスワードが機能することを期待するテストを作成し、テストハーネスを CREATE DATABASEにすることをお勧めします。使い捨てデータベース、次に DROP DATABASE 実行の最後に。プロパティファイルからデータベース接続の詳細を取得し、ターゲットプロパティ、環境変数などを構築します。

単体テストに提供するユーザーがでない限り、関心のあるデータベースがすでにある既存のPostgreSQLインスタンスを使用しても安全です。スーパーユーザー、 CREATEDB</code>を持つユーザーのみ権利。最悪の場合、他のデータベースでパフォーマンスの問題が発生します。そのため、テストのために完全に分離されたPostgreSQLインストールを実行することを好みます。

 代わりに：テスト用に使い捨てのPostgreSQLインスタンスを起動します
 
 または、本当に テストハーネスにinitdbを見つけてもらうことに熱心です およびpostgres バイナリ、 initdbを実行します データベースを作成するには、 pg_hba.confを変更します  trustへ 、 postgresを実行します ランダムポートで起動するには、ユーザーを作成し、DBを作成して、テストを実行します。複数のアーキテクチャ用のPostgreSQLバイナリをjarにバンドルし、テストを実行する前に現在のアーキテクチャ用のPostgreSQLバイナリを一時ディレクトリに解凍することもできます。
 
 個人的には、それは避けるべき大きな痛みだと思います。テストDBを設定する方がはるかに簡単です。ただし、 include_dir の登場により、少し簡単になりました。  postgresql.confでのサポート;これで、1行追加するだけで、残りのすべての構成ファイルを生成して書き込むことができます。
 PostgreSQLを使用したより迅速なテスト
 
 安全にする方法の詳細については テスト目的でPostgreSQLのパフォーマンスを向上させます。このトピックについて以前に書いた詳細な回答を参照してください：高速テストのためにPostgreSQLを最適化する
 H2のPostgreSQL方言は真の代替ではありません
 
 代わりに、PostgreSQLダイアレクトモードでH2データベースを使用してテストを実行する人もいます。これは、テストにSQLiteを使用し、本番環境にPostgreSQLを使用しているRailsの人々とほぼ同じくらい悪いことだと思います。
 
 H2はいくつかのPostgreSQL拡張機能をサポートし、PostgreSQL方言をエミュレートします。しかし、それはまさにそれです-エミュレーション。 H2はクエリを受け入れるが、PostgreSQLは受け入れない、動作が異なる領域などを見つけることができます。また、ウィンドウ関数のように、PostgreSQLがH2ではできないことをサポートする場所もたくさんあります。書き込み。
 
 このアプローチの制限を理解していて、データベースアクセスが単純な場合は、H2で問題ない可能性があります。ただし、その場合は、データベースの興味深い機能を使用していないため、データベースを抽象化するORMの候補として適しています。その場合、データベースの互換性についてはそれほど気にする必要はありません。
 テーブルスペースは答えではありません！
 
 しない 表領域を使用して、「メモリ内」データベースを作成します。とにかくパフォーマンスを大幅に向上させないので不要であるだけでなく、同じPostgreSQLインストールで気になる他のアクセスを中断するための優れた方法でもあります。 9.4のドキュメントには、次の警告が含まれています。
  
 警告 
 
 メインのPostgreSQLデータディレクトリの外にある場合でも、テーブルスペースはデータベースクラスタの不可欠な部分であり、データファイルの自律的なコレクションとして扱うことはできません。これらはメインデータディレクトリに含まれるメタデータに依存しているため、別のデータベースクラスタに接続したり、個別にバックアップしたりすることはできません。同様に、テーブルスペースを失うと（ファイルの削除、ディスク障害など）、データベースクラスタが読み取れなくなったり、できなくなったりする可能性があります。 ramdiskなどの一時ファイルシステムにテーブルスペースを配置すると、クラスター全体の信頼性が低下します。
 
 
 あまりにも多くの人がこれをやっていて問題にぶつかっているのに気づいたからです。
 
 （これを行った場合は、 mkdir  PostgreSQLを再起動するための不足しているテーブルスペースディレクトリ、次に DROP  不足しているデータベース、テーブルなど。それを行わない方がよいでしょう。）