Como instalar e configurar PostgreSQL em VPS

Tempo estimado: 30-40 minutos

Dificuldade: Intermediário

Este guia mostra como instalar e configurar PostgreSQL em uma VPS Ubuntu para uso em produção pequena ou média, com foco em segurança, acesso remoto controlado, validação e backup. A base usada nos comandos é Ubuntu 22.04 ou 24.04, mas a lógica também vale para Debian com pequenos ajustes nos nomes de pacotes e caminhos.

Antes de começar, tenha em mente uma regra simples: banco de dados em produção precisa de acesso restrito, backups testáveis e monitoramento. Se você está preparando a VPS para uma API, um painel administrativo ou um sistema interno, também vale revisar boas práticas de infraestrutura para aplicações em VPS para API. PostgreSQL funciona muito bem em servidores modestos, mas o desempenho depende bastante de CPU, RAM e armazenamento.

O que você vai aprender

Ao final deste guia, você vai ter um PostgreSQL instalado, testado e com uma configuração inicial mais segura do que a instalação padrão. Você também vai entender quais arquivos mexer, como validar cada alteração e como reverter problemas comuns sem adivinhar.

Você vai aprender a:

• Atualizar a VPS e confirmar a versão do sistema antes de instalar pacotes.
• Instalar PostgreSQL usando os repositórios oficiais do Ubuntu.
• Verificar se o serviço está ativo e aceitando conexões locais.
• Criar um banco de dados, um usuário de aplicação e permissões mínimas.
• Liberar acesso remoto apenas para um IP confiável usando postgresql.conf, pg_hba.conf e UFW.
• Aplicar ajustes iniciais de memória, conexões e logs para um ambiente de produção.
• Criar um backup lógico com pg_dump e automatizar a rotina com cron.
• Testar conexão, autenticação, porta, permissões e restauração básica.
• Resolver erros comuns, como conexão recusada, senha inválida e bloqueio por firewall.

O objetivo não é esgotar todos os recursos do PostgreSQL. A ideia é entregar uma base confiável para você subir uma aplicação real. Depois, você pode evoluir para replicação, backups incrementais, tuning avançado, observabilidade e alta disponibilidade.

Pré-requisitos

Você precisa de uma VPS com Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS, acesso SSH com usuário que possa executar sudo e um terminal local. No Windows, use PowerShell, Windows Terminal ou WSL. No Linux e macOS, o terminal padrão já atende.

Confirme que você consegue entrar no servidor por SSH. Troque 203.0.113.10 pelo IP público da sua VPS e deploy pelo seu usuário administrativo:

ssh [email protected]

A primeira conexão pode mostrar uma mensagem parecida com esta:

The authenticity of host '203.0.113.10' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Digite yes apenas se o IP estiver correto. Depois de logar, verifique o sistema:

lsb_release -a

Saída esperada:

Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble

Você também precisa saber qual IP poderá acessar o banco remotamente. Pode ser o IP fixo da sua aplicação, por exemplo 198.51.100.25. Evite liberar PostgreSQL para a internet inteira. A porta padrão 5432 costuma ser alvo de varreduras automáticas.

Se ainda está dimensionando a máquina, consulte critérios de CPU, RAM e disco em como escolher CPU, RAM e NVMe para VPS. Para bancos com escrita frequente, armazenamento rápido ajuda bastante. Em cenários com muitas consultas e índices grandes, uma VPS com NVMe tende a reduzir latência de leitura e escrita.

Passo 1: Preparar a VPS e atualizar o sistema

Comece atualizando a lista de pacotes e aplicando correções disponíveis. Essa etapa reduz conflitos de dependência e garante que bibliotecas usadas pelo PostgreSQL estejam em versões recentes. Antes de qualquer mudança maior em produção, faça snapshot no painel do provedor ou tenha um backup externo. Atualização de pacotes costuma ser segura, mas pode reiniciar serviços dependendo do ambiente.

Execute:

sudo apt update

Você deve ver algo parecido com:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Agora aplique as atualizações:

sudo apt upgrade -y

Saída esperada, com variações conforme a VPS:

Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Instale ferramentas úteis para diagnóstico, conexão e backup:

sudo apt install -y curl gnupg2 ca-certificates lsb-release ufw gzip

Saída esperada:

Reading package lists... Done
Building dependency tree... Done
curl is already the newest version.
ufw is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Verifique o horário do servidor. Banco de dados com horário errado causa logs confusos, expiração de tokens incorreta e problemas em auditoria:

timedatectl

Procure por System clock synchronized: yes:

System clock synchronized: yes
              Time zone: Etc/UTC (UTC, +0000)

Se você quiser usar o fuso de São Paulo nos logs, configure assim:

sudo timedatectl set-timezone America/Sao_Paulo

Confirme novamente:

timedatectl | grep "Time zone"

Saída esperada:

Time zone: America/Sao_Paulo (-03, -0300)

Com o sistema atualizado, você pode instalar o PostgreSQL com menos risco de erro por pacote antigo ou repositório desatualizado.

Passo 2: Instalar PostgreSQL e validar o serviço

O Ubuntu já oferece PostgreSQL nos repositórios oficiais. Para muitos ambientes, essa versão é suficiente e recebe atualizações de segurança pelo próprio sistema. Se você precisa de uma versão específica, como PostgreSQL 16 em uma distribuição mais antiga, use o repositório oficial do PostgreSQL. Neste guia, vamos usar o pacote padrão do Ubuntu para manter o processo direto e reproduzível.

Instale o servidor PostgreSQL e o pacote de extras:

sudo apt install -y postgresql postgresql-contrib

Saída esperada:

Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  postgresql postgresql-contrib postgresql-16
Setting up postgresql-16 ...
Creating new PostgreSQL cluster 16/main ...

Verifique se o serviço subiu automaticamente:

sudo systemctl status postgresql --no-pager

Você deve ver active (exited) ou active (running), dependendo da versão e do modelo de unidade do systemd:

● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled)
     Active: active (exited)

Agora veja os clusters PostgreSQL disponíveis:

pg_lsclusters

Saída esperada:

Ver Cluster Port Status Owner    Data directory              Log file
16  main    5432 online postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.log

Se o status aparecer como down, tente iniciar:

sudo systemctl start postgresql

Valide a porta local:

sudo ss -ltnp | grep 5432

Em uma instalação padrão, o PostgreSQL escuta apenas em 127.0.0.1 e ::1:

LISTEN 0 244 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=1842,fd=7))
LISTEN 0 244 [::1]:5432    [::]:*    users:(("postgres",pid=1842,fd=6))

Faça um teste local usando o usuário administrativo do PostgreSQL, chamado postgres:

sudo -u postgres psql -c "SELECT version();"

Saída esperada:

PostgreSQL 16.3 (Ubuntu 16.3-0ubuntu0.24.04.1) on x86_64-pc-linux-gnu
(1 row)

Com isso, o servidor está instalado e respondendo localmente. No próximo passo, você vai criar credenciais separadas para a aplicação, em vez de usar o superusuário postgres.

Passo 3: Criar banco, usuário e permissões

Aplicações não devem conectar ao banco usando o usuário postgres. Esse usuário é administrativo e tem privilégios amplos. A prática mais segura é criar um usuário específico para a aplicação, com senha forte e permissões somente no banco necessário. Neste exemplo, vamos criar o banco appdb e o usuário appuser.

Gere uma senha forte no servidor. Você pode usar este comando para produzir uma senha aleatória de 32 caracteres:

openssl rand -base64 24

Saída esperada:

nR7YpDq4Lx9mV2sT8aQ6zB1cE3fG5hJk

Guarde a senha em um gerenciador seguro. Não salve credenciais em histórico de comandos quando estiver trabalhando em ambiente compartilhado. Agora entre no psql como postgres:

sudo -u postgres psql

Você verá o prompt:

psql (16.3)
Type "help" for help.

postgres=#

Execute os comandos SQL abaixo. Troque a senha pelo valor gerado no seu ambiente:

CREATE DATABASE appdb;
CREATE USER appuser WITH ENCRYPTED PASSWORD 'nR7YpDq4Lx9mV2sT8aQ6zB1cE3fG5hJk';
GRANT CONNECT ON DATABASE appdb TO appuser;
\c appdb
GRANT USAGE, CREATE ON SCHEMA public TO appuser;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO appuser;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE, SELECT ON SEQUENCES TO appuser;

O output deve ser semelhante a:

CREATE DATABASE
CREATE ROLE
GRANT
You are now connected to database "appdb" as user "postgres".
GRANT
ALTER DEFAULT PRIVILEGES
ALTER DEFAULT PRIVILEGES

Saia do psql:

\q

Teste a autenticação local via TCP. O comando abaixo pede senha e conecta no banco criado:

psql -h 127.0.0.1 -U appuser -d appdb -c "SELECT current_user, current_database();"

Saída esperada:

 current_user | current_database
--------------+------------------
 appuser      | appdb
(1 row)

Se receber psql: command not found, instale o cliente:

sudo apt install -y postgresql-client

Agora você tem um banco separado, um usuário de aplicação e um teste objetivo de login.

Passo 4: Configurar acesso remoto com segurança

Por padrão, o PostgreSQL aceita conexões locais. Para uma aplicação em outra VPS conectar, você precisa alterar dois arquivos: postgresql.conf, que define em quais endereços o serviço escuta, e pg_hba.conf, que controla quem pode autenticar. Faça backup antes de editar. Esse backup é simples, mas salva muito tempo se uma linha ficar errada.

Descubra a versão e o caminho do cluster:

pg_lsclusters

Saída esperada:

Ver Cluster Port Status Owner    Data directory
16  main    5432 online postgres /var/lib/postgresql/16/main

Crie cópias dos arquivos principais:

sudo cp /etc/postgresql/16/main/postgresql.conf /etc/postgresql/16/main/postgresql.conf.bak.$(date +%F)
sudo cp /etc/postgresql/16/main/pg_hba.conf /etc/postgresql/16/main/pg_hba.conf.bak.$(date +%F)

Verifique se os backups existem:

ls -lh /etc/postgresql/16/main/*.bak.*

Saída esperada:

-rw-r--r-- 1 root root 30K Aug 24 10:20 postgresql.conf.bak.2026-08-24
-rw-r--r-- 1 root root  6K Aug 24 10:20 pg_hba.conf.bak.2026-08-24

Edite o postgresql.conf:

sudo nano /etc/postgresql/16/main/postgresql.conf

Procure listen_addresses e configure:

listen_addresses = '*'

Agora edite o controle de acesso:

sudo nano /etc/postgresql/16/main/pg_hba.conf

Adicione ao final uma linha permitindo apenas o IP da aplicação, aqui 198.51.100.25:

host    appdb    appuser    198.51.100.25/32    scram-sha-256

Não use 0.0.0.0/0 em produção. Isso expõe o banco para qualquer origem e aumenta muito o risco de ataque por força bruta. Antes de reiniciar, valide a sintaxe dos arquivos:

sudo -u postgres postgres --config-file=/etc/postgresql/16/main/postgresql.conf --check

Saída esperada:

Sem output significa que a validação não encontrou erro. Reinicie o cluster:

sudo systemctl restart postgresql

Confirme que a porta agora escuta em todas as interfaces:

sudo ss -ltnp | grep 5432

Saída esperada:

LISTEN 0 244 0.0.0.0:5432 0.0.0.0:* users:(("postgres",pid=2210,fd=7))
LISTEN 0 244 [::]:5432    [::]:*    users:(("postgres",pid=2210,fd=6))

Falta liberar o firewall somente para o IP autorizado.

Passo 5: Aplicar firewall e ajustes básicos de produção

Se você ainda não usa firewall na VPS, configure UFW com cuidado para não bloquear seu próprio SSH. Primeiro, permita SSH. Em Ubuntu, o perfil pode aparecer como OpenSSH. Confira antes:

sudo ufw app list

Saída esperada:

Available applications:
  OpenSSH

Permita SSH e o IP da aplicação na porta do PostgreSQL:

sudo ufw allow OpenSSH
sudo ufw allow from 198.51.100.25 to any port 5432 proto tcp

Saída esperada:

Rule added
Rule added

Ative o UFW apenas depois de permitir SSH. Se você estiver conectado por uma porta SSH personalizada, libere essa porta antes:

sudo ufw enable

Confirme digitando y. A saída deve ser:

Firewall is active and enabled on system startup

Verifique as regras:

sudo ufw status numbered

Saída esperada:

Status: active

[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 5432/tcp                   ALLOW IN    198.51.100.25

Agora aplique ajustes básicos no PostgreSQL. Esses valores são conservadores para uma VPS com 2 GB de RAM. Faça backup antes, como já fizemos no passo anterior. Edite:

sudo nano /etc/postgresql/16/main/postgresql.conf

Ajuste ou adicione:

max_connections = 50
shared_buffers = 512MB
effective_cache_size = 1536MB
maintenance_work_mem = 128MB
work_mem = 8MB
log_min_duration_statement = 1000
log_checkpoints = on
log_connections = on
log_disconnections = on

Esses parâmetros não são mágicos. shared_buffers reserva memória para cache interno, effective_cache_size informa ao otimizador quanto cache do sistema pode existir, e work_mem afeta operações de ordenação e hash por conexão. Se sua VPS tem menos RAM, reduza. Se tem mais, teste com métricas.

Valide a configuração:

sudo -u postgres postgres --config-file=/etc/postgresql/16/main/postgresql.conf --check

Sem output indica sintaxe válida. Reinicie:

sudo systemctl restart postgresql

Confirme os valores aplicados:

sudo -u postgres psql -c "SHOW shared_buffers; SHOW max_connections; SHOW log_min_duration_statement;"

Saída esperada:

 shared_buffers
----------------
 512MB
(1 row)

 max_connections
-----------------
 50
(1 row)

 log_min_duration_statement
----------------------------
 1s
(1 row)

Com firewall e tuning inicial prontos, o banco já está mais adequado para tráfego real.

Passo 6: Configurar backup lógico com pg_dump

Backup não é backup até você conseguir restaurar. Neste passo, você vai criar uma rotina simples com pg_dump, compressão e retenção local de 7 dias. Para produção crítica, envie os arquivos para armazenamento externo, como object storage, outro servidor ou serviço de backup. Manter backup apenas na mesma VPS não protege contra perda do disco.

Crie um diretório seguro:

sudo mkdir -p /var/backups/postgresql
sudo chown postgres:postgres /var/backups/postgresql
sudo chmod 700 /var/backups/postgresql

Verifique permissões:

ls -ld /var/backups/postgresql

Saída esperada:

drwx------ 2 postgres postgres 4096 Aug 24 10:45 /var/backups/postgresql

Faça um backup manual do banco appdb:

sudo -u postgres pg_dump -F c -d appdb -f /var/backups/postgresql/appdb_$(date +%F_%H%M).dump

Liste o arquivo:

sudo ls -lh /var/backups/postgresql

Saída esperada:

-rw-r--r-- 1 postgres postgres 28K Aug 24 10:47 appdb_2026-08-24_1047.dump

Teste se o arquivo é legível pelo PostgreSQL:

sudo -u postgres pg_restore -l /var/backups/postgresql/appdb_$(date +%F_%H%M).dump

Esse comando pode falhar porque o minuto mudou entre o backup e o teste. Use o nome real listado pelo ls. Exemplo:

sudo -u postgres pg_restore -l /var/backups/postgresql/appdb_2026-08-24_1047.dump | head

Saída esperada:

;
; Archive created at 2026-08-24 10:47:12 -03
;     dbname: appdb
;     TOC Entries: 12

Agora crie um script:

sudo nano /usr/local/bin/backup-appdb.sh

Conteúdo:

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/var/backups/postgresql"
DB_NAME="appdb"
DATE="$(date +%F_%H%M)"
/usr/bin/pg_dump -F c -d "$DB_NAME" -f "$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
find "$BACKUP_DIR" -type f -name "${DB_NAME}_*.dump" -mtime +7 -delete

A linha find apaga backups locais com mais de 7 dias. Ela é destrutiva por intenção, então revise o caminho e o padrão antes de ativar. Dê permissão:

sudo chmod 750 /usr/local/bin/backup-appdb.sh
sudo chown postgres:postgres /usr/local/bin/backup-appdb.sh

Teste:

sudo -u postgres /usr/local/bin/backup-appdb.sh

Se não houver output, o script rodou com sucesso. Agende no cron:

sudo -u postgres crontab -e

Adicione:

15 2 * * * /usr/local/bin/backup-appdb.sh

Verifique:

sudo -u postgres crontab -l

Saída esperada:

15 2 * * * /usr/local/bin/backup-appdb.sh

Verificação e testes

Agora valide tudo como se fosse uma aplicação real. Primeiro, confira o serviço:

sudo systemctl is-active postgresql

Saída esperada:

active

Confira o cluster:

pg_lsclusters

Saída esperada:

Ver Cluster Port Status Owner    Data directory
16  main    5432 online postgres /var/lib/postgresql/16/main

Teste criação de tabela com o usuário da aplicação:

PGPASSWORD='nR7YpDq4Lx9mV2sT8aQ6zB1cE3fG5hJk' psql -h 127.0.0.1 -U appuser -d appdb -c "CREATE TABLE IF NOT EXISTS healthcheck (id serial PRIMARY KEY, checked_at timestamptz DEFAULT now()); INSERT INTO healthcheck DEFAULT VALUES; SELECT * FROM healthcheck ORDER BY id DESC LIMIT 1;"

Saída esperada:

CREATE TABLE
INSERT 0 1
 id |          checked_at
----+-------------------------------
  1 | 2026-08-24 11:10:22.123456-03
(1 row)

Teste a partir da VPS da aplicação ou da sua máquina autorizada. Instale o cliente, se necessário, e conecte ao IP do servidor PostgreSQL:

psql -h 203.0.113.10 -p 5432 -U appuser -d appdb -c "SELECT inet_server_addr(), inet_client_addr();"

Saída esperada:

 inet_server_addr | inet_client_addr
------------------+------------------
 203.0.113.10     | 198.51.100.25
(1 row)

Veja os logs recentes:

sudo tail -n 30 /var/log/postgresql/postgresql-16-main.log

Você deve ver conexões e desconexões registradas, sem erros repetidos:

LOG:  connection authorized: user=appuser database=appdb
LOG:  disconnection: session time: 0:00:00.058 user=appuser database=appdb

Por fim, confirme backups:

sudo -u postgres /usr/local/bin/backup-appdb.sh && sudo ls -lh /var/backups/postgresql | tail

Saída esperada:

-rw-r--r-- 1 postgres postgres 32K Aug 24 11:15 appdb_2026-08-24_1115.dump

Se todos esses testes passarem, sua instalação está funcional, protegida por firewall e com backup lógico básico.

Troubleshooting

Problema 1: connection refused ao conectar remotamente. Esse erro costuma indicar que o PostgreSQL não está escutando no IP público ou que a porta está bloqueada. No servidor, rode:

sudo ss -ltnp | grep 5432

Se aparecer apenas 127.0.0.1:5432, revise listen_addresses = '*' em /etc/postgresql/16/main/postgresql.conf e reinicie o serviço. Depois confira o UFW:

sudo ufw status numbered

A regra deve liberar 5432/tcp somente para o IP correto. Se você está testando de outro IP, o bloqueio é esperado.

Problema 2: no pg_hba.conf entry for host. O PostgreSQL recebeu a conexão, mas não encontrou regra de autorização. Veja o IP real do cliente no log:

sudo tail -n 50 /var/log/postgresql/postgresql-16-main.log

Adicione uma linha específica no pg_hba.conf, como:

host    appdb    appuser    198.51.100.25/32    scram-sha-256

Recarregue sem reiniciar conexões ativas:

sudo systemctl reload postgresql

Problema 3: password authentication failed for user. Confirme se a aplicação usa o usuário, banco e senha corretos. Para redefinir a senha, entre como administrador:

sudo -u postgres psql -c "ALTER USER appuser WITH ENCRYPTED PASSWORD 'NovaSenhaForteAqui123456';"

Depois teste:

psql -h 127.0.0.1 -U appuser -d appdb -c "SELECT 1;"

Problema 4: PostgreSQL não reinicia após editar configuração. Rode a validação:

sudo -u postgres postgres --config-file=/etc/postgresql/16/main/postgresql.conf --check

Se houver erro, restaure o backup criado:

sudo cp /etc/postgresql/16/main/postgresql.conf.bak.2026-08-24 /etc/postgresql/16/main/postgresql.conf
sudo systemctl restart postgresql

Troque a data pelo arquivo real existente na sua VPS.

Próximos passos

Com a instalação funcionando, conecte sua aplicação usando variáveis de ambiente, nunca credenciais fixas no código. Uma string comum fica assim:

postgresql://appuser:[email protected]:5432/appdb?sslmode=prefer

Se a aplicação roda na mesma VPS, use 127.0.0.1 e mantenha o acesso remoto desativado. Se roda em outra VPS, mantenha a regra por IP e monitore logs de autenticação. Também considere habilitar TLS no PostgreSQL quando a conexão atravessar redes públicas, especialmente se você não usa VPN privada entre servidores.

Depois, evolua a rotina de backup. Copie os dumps para armazenamento externo, teste restauração em uma VPS separada e documente o tempo necessário para recuperar o serviço. Para bancos maiores, avalie ferramentas como pgBackRest ou WAL-G, que suportam backups físicos, retenção avançada e recuperação ponto no tempo.

Monitore CPU, RAM, I/O de disco, conexões e queries lentas. O parâmetro log_min_duration_statement = 1000 já ajuda a encontrar consultas acima de 1 segundo. Com dados reais, você pode ajustar índices, work_mem, número de conexões e pool de conexões com PgBouncer. Para produção com crescimento rápido, revise o tamanho da VPS, principalmente memória e disco NVMe, antes que gargalos apareçam em horário de pico.