Não use o Postgres… embarcado.

Não é a primeira vez, não será a última que aparece um maluco com esse tipo de ideia. Já ouvi gente querendo rodar Postgres até em celular. O pessoal se empolga com o Postgres. Ele é bacana e coisa e tal, mas tem limitações. Ele pode não ser a solução ideal para aplicações embarcadas. Ok, eu já vi aplicações rodando com versões antiquíssimas do Postgres. Pode passar anos sem dar nenhum problema. Mas veja bem… o PostgreSQL nasceu para rodar num servidor, com alguém de olho nele.

Sim, dá para rodar um PostgreSQL até em PS2, mas não faça isso. Considere algumas questões:

• Se você vai criar uma base com um único usuário, o PostgreSQL pode ser um exagero para você. Já pensou no SQLite? Leve e compacto. Um único arquivo para toda a base. Uma única lib para a sua aplicação. Simples não? Veja algumas opções em: “Database Overkill“
• O Postgres é bastante exigente com discos. São vários componentes que não envolvem apenas os datafiles: temos o WAL, clog, tablespaces, archive, etc. Claro, você pode instalar tudo num único diretório, mas para ganhar desempenho, toda uma arquitetura tem de ser pensada. Em geral, o mínimo que se faz é criar sua base numa partição separada do restante do SO.
• Já vi gente querendo rodar PostgreSQL em pen drive, juro. Primeiro que o Postgres não roda em FAT (bate na madeira…), segundo que você não deve jamais desligar uma base no tranco, a não ser que esteja testando a robustez do mesmo. A gente tinha um “servidor de testes” bichado que dava kernel panic direto aqui. O Postgres nunca corrompeu em vários meses com travamentos diários. Mas daí a ter a ideia de colocar sua base num “disco” que o usuário pode “puxar da tomada” é demais para qualquer um.
• Configurar a segurança do Postgres é chato. Um zilhão de pessoas reclamam que o  “Meu Postgres não conecta” nas primeiras vezes que usam o Postgres. Se você vai rodar uma base num notebook, isso realmente não importa muito. Afinal, quem tem acesso ao equipamento fisicamente, sempre pode ter acesso ao usuário root (ou administrador no windows).
• Fazer backup do Postgres dá trabalho. O dump tem um monte de opções para escolher. O backup físico também tem suas peculiaridades. Num SQLite, você só precisa copiar UM arquivo.
• E se a base crescer? Índices, reindex, analyze e outras coisas pode precisar de ajuste. Quem é que vai fazer isso?
• E se a versão ficar velha, quem vai fazer o upgrade da versão? Conheci um cliente que tinha sua aplicação instalada em mais de 1000 clientes. Eles levaram mais de um ano para migrar da versão 7.4 e 8.0 para a 8.1, mas nesta época só tinham uns 200 clientes. Hoje, é claro, eles estão partindo para o SaaS.

Enfim, existem soluções de banco de dados que são otimizadas para trabalhar embarcadas. Não, não estou falando do Access (que só serve mesmo para dar dor de cabeça). Mas assim como o SQLite, você pode usar XML, texto puro, Berkeley DB, Firebird entre outros. A vantagem é que eles vão consumir muito menos recursos do SO e vão ser muito mais fácil de manter. O PostgreSQL é um dragão que quer o servidor só para ele. É neste terreno que ele tem se tornado um “database killer”.