(Movendo minha resposta de Using in-memory PostgreSQL e generalizando-a):
Você não pode executar Pg em processo, na memória
Não consigo descobrir como executar o banco de dados Postgres na memória para teste. É possível?
Não, não é possível. O PostgreSQL é implementado em C e compilado para o código da plataforma. Ao contrário do H2 ou Derby, você não pode simplesmente carregar o
jar e acione-o como um banco de dados de memória descartável. Ao contrário do SQLite, que também é escrito em C e compilado para o código da plataforma, o PostgreSQL também não pode ser carregado no processo. Requer vários processos (um por conexão) porque é uma arquitetura de multiprocessamento, não de multithreading. O requisito de multiprocessamento significa que você deve inicie o postmaster como um processo autônomo.
Em vez disso:pré-configurar uma conexão
Eu sugiro simplesmente escrever seus testes para esperar que um nome de host/nome de usuário/senha específico funcione, e ter o equipamento de teste
CREATE DATABASE um banco de dados descartável, então DROP DATABASE no final da corrida. Obtenha os detalhes da conexão do banco de dados de um arquivo de propriedades, propriedades de destino de compilação, variável de ambiente etc. É seguro usar uma instância existente do PostgreSQL em que você já possui bancos de dados importantes, desde que o usuário fornecido para seus testes de unidade não um superusuário, apenas um usuário com
CREATEDB direitos. Na pior das hipóteses, você criará problemas de desempenho nos outros bancos de dados. Eu prefiro executar uma instalação do PostgreSQL completamente isolada para teste por esse motivo. Em vez disso:inicie uma instância descartável do PostgreSQL para teste
Como alternativa, se você estiver realmente interessado, você pode fazer com que seu equipamento de teste localize o
initdb e postgres binários, execute initdb para criar um banco de dados, modifique pg_hba.conf para trust , execute postgres para iniciá-lo em uma porta aleatória, crie um usuário, crie um banco de dados e execute os testes. Você pode até mesmo agrupar os binários do PostgreSQL para várias arquiteturas em um jar e descompactar os da arquitetura atual em um diretório temporário antes de executar os testes. Pessoalmente, acho que é uma grande dor que deve ser evitada; é muito mais fácil ter apenas um banco de dados de teste configurado. No entanto, ficou um pouco mais fácil com o advento do
include_dir suporte em postgresql.conf; agora você pode apenas anexar uma linha e escrever um arquivo de configuração gerado para todo o resto. Testes mais rápidos com PostgreSQL
Para obter mais informações sobre como com segurança melhorar o desempenho do PostgreSQL para fins de teste, veja uma resposta detalhada que escrevi sobre este tópico anteriormente:Otimizar PostgreSQL para testes rápidos
O dialeto PostgreSQL do H2 não é um substituto verdadeiro
Algumas pessoas usam o banco de dados H2 no modo de dialeto PostgreSQL para executar testes. Acho que isso é quase tão ruim quanto o pessoal do Rails usando SQLite para testes e PostgreSQL para implantação de produção.
O H2 suporta algumas extensões do PostgreSQL e emula o dialeto do PostgreSQL. No entanto, é apenas isso - uma emulação. Você encontrará áreas onde o H2 aceita uma consulta mas o PostgreSQL não, onde o comportamento difere, etc. Você também encontrará muitos lugares onde o PostgreSQL suporta fazer algo que o H2 simplesmente não pode - como funções de janela, no escrita.
Se você entender as limitações dessa abordagem e seu acesso ao banco de dados for simples, o H2 pode ser adequado. Mas, nesse caso, você provavelmente é um candidato melhor para um ORM que abstrai o banco de dados porque você não está usando seus recursos interessantes de qualquer maneira - e, nesse caso, você não precisa mais se preocupar com a compatibilidade do banco de dados.
Os espaços de tabela não são a resposta!
não use um tablespace para criar um banco de dados "na memória". Não apenas é desnecessário, pois não ajudará significativamente o desempenho, mas também é uma ótima maneira de interromper o acesso a qualquer outro que você possa se importar na mesma instalação do PostgreSQL. A documentação 9.4 agora contém o seguinte aviso:
AVISO
Embora localizados fora do diretório principal de dados do PostgreSQL, os tablespaces são parte integrante do cluster de banco de dados e não podem ser tratados como uma coleção autônoma de arquivos de dados. Eles são dependentes de metadados contidos no diretório de dados principal e, portanto, não podem ser anexados a um cluster de banco de dados diferente ou fazer backup individualmente. Da mesma forma, se você perder um tablespace (exclusão de arquivo, falha de disco, etc.), o cluster de banco de dados pode ficar ilegível ou incapaz Colocar um tablespace em um sistema de arquivos temporário como um disco ram arrisca a confiabilidade de todo o cluster.
porque notei que muitas pessoas estavam fazendo isso e tendo problemas.
(Se você fez isso você pode
mkdir o diretório de tablespace ausente para que o PostgreSQL inicie novamente, então DROP os bancos de dados, tabelas etc. ausentes. É melhor não fazer isso.) 
