VPS para um banco de dados PostgreSQL (auto-hospedado, controle total)

Há um momento em que o PostgreSQL gerenciado deixa de ser conveniente: você quer uma extensão que a camada não oferece, quer ver o plano de consulta real e ajustar o work_mem, quer superusuário. Quando você quer possuir o Postgres — a configuração, a versão, as extensões, o cronograma de backup — um VPS com root completo é a resposta honesta. Esta é a configuração específica de PostgreSQL; para o quadro mais amplo de "auto-hospedar um banco de dados" (Postgres vs Redis, onde uma máquina compartilhada é errada), veja o caso de uso de banco de dados geral.

Por que auto-hospedar PostgreSQL

Na sua própria máquina você obtém o que as camadas gerenciadas racionam:

• Todo o postgresql.conf — shared_buffers, work_mem, max_connections, configurações de WAL, ajustados à sua carga, não um padrão de fornecedor.
• Qualquer extensão. pgvector para embeddings, PostGIS para geoespacial, TimescaleDB para séries temporais, pg_cron, pg_stat_statements — instale o que precisar. É aqui que uma camada gerenciada mais frequentemente diz não.
• Sua versão maior, atualizada no seu cronograma, não no do provedor.
• Superusuário e o SO por baixo — mova o diretório de dados, ajuste o kernel, rode replicação por streaming para uma segunda máquina.

Se o pgvector é o motivo de você estar aqui, note que Postgres mais pgvector é um armazenamento de vetores completo em uma máquina — o mesmo bloco de construção por trás de uma pilha RAG auto-hospedada e da memória de agente.

Configure (Ubuntu 24.04, Docker)

# docker-compose.yml — PostgreSQL 16 (+ pgvector via the pgvector image)
services:
  db:
    image: pgvector/pgvector:pg16
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me-strong
      POSTGRES_DB: app
    command: ["postgres", "-c", "shared_buffers=512MB", "-c", "work_mem=32MB"]
    volumes: ["/srv/pg:/var/lib/postgresql/data"]
    ports: ["127.0.0.1:5432:5432"]   # localhost only; see below to expose safely

docker compose up -d
docker compose exec db psql -U app -c "CREATE EXTENSION IF NOT EXISTS vector;"

Vinculado a 127.0.0.1, ele serve uma app na mesma máquina sem expor nada. Para deixar outros servidores entrarem, essa é a próxima seção.

Deixar outros servidores se conectarem — com segurança

No momento em que outra máquina precisa do banco de dados, duas coisas mudam:

1. Um endereço estável e roteável — um plano com IPv4 dedicado (Small-IP US$ 16, Medium-IP US$ 20). Planos NAT compartilham um IP de saída, bom para saída mas não para ser um banco que outros discam.
2. Firewall pesado. Abra a 5432 apenas para os IPs de cliente específicos, nunca 0.0.0.0/0, e exija TLS. Uma porta Postgres aberta na internet pública é encontrada em minutos — tranque-a com um firewall UFW.

Backups são seu trabalho

Auto-hospedar significa que os backups ficam por sua conta, e a regra é: faça-os antes de precisar deles. pg_dump em cron para backups lógicos, ou arquivamento de WAL para recuperação a um ponto no tempo em tudo que você se importa. Envie os dumps para fora da máquina e teste uma restauração pelo menos uma vez — um backup que você nunca restaurou é uma esperança, não um backup. Um add-on de backups gerenciados está disponível se você preferir não rodá-lo você mesmo.

Por que EQVPS para PostgreSQL

• Root completo, superusuário, sua configuração — a partir de US$ 8/mês, NVMe (RAID1) que importa assim que um banco de dados e seu WAL escrevem ao mesmo tempo.
• Sem KYC, pagamento em cripto. E-mail para registrar, USDC/USDT para pagar.
• UE (Alemanha, Finlândia), root em ~60 segundos. Traga seu schema e siga.

Caso de uso de banco de dados geral (visão geral Postgres/Redis) → · RAG auto-hospedado em escala →