--- title: "Como instalar PostgreSQL na VPS Ubuntu com segurança" description: "Instale o PostgreSQL na VPS Ubuntu, crie usuário e banco, libere acesso remoto só por IP, agende backups com pg_dump e ajuste memória e conexões." url: "https://streethosting.com.br/guias/vps/instalar-postgresql-vps-ubuntu" category: "vps" slug: "instalar-postgresql-vps-ubuntu" datePublished: "2026-06-18" dateModified: "2026-09-28" author: "Equipe StreetHosting" difficulty: "intermediario" language: "pt-BR" keywords: - "instalar postgresql vps ubuntu" - "postgresql ubuntu server configurar" - "postgres vps linux produção" - "postgresql criar banco usuario ubuntu" - "backup postgresql pg_dump cron" - "otimizar postgresql shared_buffers" --- # PostgreSQL na VPS Ubuntu: acesso seguro, backup e otimização PostgreSQL é o banco relacional open source mais completo e o padrão de muitas aplicações modernas. Veja como instalar na VPS Ubuntu, criar usuário e banco para a aplicação, entender a autenticação, liberar acesso remoto sem expor a porta, agendar backups e ajustar a memória. > **Resposta rápida** > > Para **instalar PostgreSQL na VPS Ubuntu**, rode `sudo apt install postgresql`, crie um usuário e um banco próprios para a aplicação e mantenha o serviço escutando só localmente. Para acesso remoto, libere um IP específico no *pg_hba.conf* e no firewall, nunca a porta 5432 inteira. Agende um `pg_dump` diário e ajuste *shared_buffers* e conexões ao tamanho da VPS. ## Instalar o PostgreSQL 1. Atualize os pacotes: `sudo apt update` 2. Instale o PostgreSQL: `sudo apt install -y postgresql postgresql-contrib` 3. Confirme que o serviço está rodando: `sudo systemctl status postgresql` 4. Veja a versão e o cluster criado: `pg_lsclusters` O Ubuntu 24.04 instala o PostgreSQL 16, e o 22.04 instala o 14. O pacote já cria um cluster chamado *main*, liga o serviço e o configura para subir no boot. Os arquivos de configuração ficam em `/etc/postgresql/16/main/` e os dados em `/var/lib/postgresql/16/main/`. Nos comandos deste guia, troque 16 pela versão que o `pg_lsclusters` mostrar. > **Dica** > > A versão do Ubuntu recebe correções de segurança durante todo o suporte do sistema. Se você precisa de uma versão principal mais nova, o repositório oficial do projeto, o PGDG, tem um script que o configura: `sudo apt install -y postgresql-common && sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh`. Depois instale a versão desejada, como `postgresql-18`. ## Criar usuário e banco O PostgreSQL cria um superusuário chamado *postgres*, ligado ao usuário de sistema de mesmo nome. Entre no shell com ele: ``` sudo -u postgres psql ``` Dentro do psql, crie um usuário dedicado para a aplicação e um banco que pertença a ele: ``` CREATE USER meu_usuario; \password meu_usuario CREATE DATABASE meu_banco OWNER meu_usuario; \q ``` O `\password` pede a senha duas vezes e grava só a versão cifrada, sem deixar o texto no histórico do psql. O detalhe importante é o `OWNER`: desde o PostgreSQL 15, usuários comuns não podem mais criar tabelas no schema *public* de um banco que não é deles. Um `GRANT ALL PRIVILEGES ON DATABASE` não resolve, porque ele dá direito de conectar e criar schemas, mas não de criar tabelas no *public*. Criar o banco já com o dono certo evita o erro *permission denied for schema public* na primeira migração da aplicação. > **Atenção** > > Nunca use o usuário postgres na aplicação. Crie um usuário por aplicação, com acesso só ao banco que ela usa. Se o código vazar, o estrago fica restrito àquele banco. ## Como a autenticação funciona O arquivo `/etc/postgresql/16/main/pg_hba.conf` decide quem conecta, de onde e com qual método. Ele é lido de cima para baixo, e vale a primeira linha que combinar com a conexão. Na instalação do Ubuntu, as regras padrão são estas: | Tipo de conexão | Método padrão | O que significa | | --- | --- | --- | | Local, pelo socket Unix | peer | O nome do usuário do sistema precisa ser igual ao do banco, sem senha | | TCP em 127.0.0.1 ou ::1 | SCRAM | Qualquer usuário do banco, com senha verificada por SCRAM | | TCP vindo de outro IP | Nenhuma regra | Recusado até você criar uma regra | Na prática, isso significa que uma aplicação na mesma VPS que conecta em *127.0.0.1* com usuário e senha já funciona sem editar nada. É também por isso que `psql -U meu_usuario meu_banco` falha com erro de autenticação peer: sem o `-h 127.0.0.1`, o psql usa o socket e a regra peer. Se quiser senha também pelo socket, acrescente a linha abaixo antes da regra `local all all peer` e recarregue com `sudo systemctl reload postgresql`: ``` local meu_banco meu_usuario scram-sha-256 ``` Tutoriais antigos usam o método *md5*. Prefira o `scram-sha-256`, padrão desde o PostgreSQL 14. No md5, o hash guardado no servidor já basta para autenticar, então quem o obtém entra sem saber a senha; o SCRAM elimina esse atalho. ## Conectar com a aplicação A string de conexão padrão do PostgreSQL, que a maioria dos drivers e ORMs aceita em uma variável como *DATABASE_URL*: ``` postgresql://meu_usuario:SENHA@127.0.0.1:5432/meu_banco ``` - **Node.js:** biblioteca `pg` ou ORMs como Prisma e Drizzle. Veja o guia de [API Node.js na VPS](https://streethosting.com.br/guias/vps/hospedar-api-nodejs-vps-brasil). - **Python:** `psycopg` ou SQLAlchemy, comuns em projetos FastAPI e Django. - **PHP:** PDO com o driver pgsql; no Laravel, basta `DB_CONNECTION=pgsql` no *.env*. Senhas com *@*, *:* ou */* precisam ser codificadas na URL. Para evitar o problema, gere senhas só com letras e números, por exemplo com `openssl rand -hex 24`. ## Acesso remoto seguro Se a aplicação roda na mesma VPS, pule esta seção: o banco escutando só em localhost é a configuração mais segura. Para aceitar conexões de outro servidor, três arquivos mudam. No `postgresql.conf`, o *listen_addresses* recebe os endereços da própria VPS em que o PostgreSQL vai escutar, e não o IP do cliente, que é um erro comum: ``` # /etc/postgresql/16/main/postgresql.conf listen_addresses = 'localhost,10.8.0.1' # /etc/postgresql/16/main/pg_hba.conf hostssl meu_banco meu_usuario IP_DO_SERVIDOR_APP/32 scram-sha-256 # firewall sudo ufw allow from IP_DO_SERVIDOR_APP to any port 5432 proto tcp sudo systemctl restart postgresql ``` No exemplo, 10.8.0.1 é o endereço da VPS em um túnel [WireGuard](https://streethosting.com.br/guias/vps/proteger-vps-wireguard-vpn); se não usar VPN, coloque o IP público da VPS. A regra `hostssl` só aceita a conexão com TLS, e o PostgreSQL do Ubuntu já vem com TLS ligado, usando um certificado autoassinado. No cliente, acrescente `?sslmode=require` na URL. A mudança em *listen_addresses* exige restart; mudanças só no *pg_hba.conf* pedem apenas reload. As regras de firewall seguem o [guia de UFW na VPS Ubuntu](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu). Para administrar pelo DBeaver ou pelo pgAdmin do seu computador, não abra a porta: crie um túnel com `ssh -N -L 5433:127.0.0.1:5432 usuario@IP_DA_VPS` e conecte em *localhost*, porta 5433. > **Atenção** > > Nunca combine `listen_addresses = '*'` com uma regra *0.0.0.0/0* no pg_hba.conf e a porta aberta no firewall. Robôs testam senhas na porta 5432 o tempo todo, e um PostgreSQL invadido costuma virar minerador de criptomoeda. ## Otimização básica A configuração padrão do PostgreSQL é conservadora de propósito, para rodar até em máquinas minúsculas. Em uma VPS com alguns GB de RAM, quatro parâmetros de memória e o limite de conexões fazem a maior diferença: - **shared_buffers:** o cache próprio do PostgreSQL. O ponto de partida é 25% da RAM; mais que isso raramente ajuda, porque o cache de arquivos do sistema também guarda os dados. Mudar exige restart. - **effective_cache_size:** não reserva memória. É uma estimativa, usada pelo planejador de consultas, de quanto cache existe somando o do PostgreSQL e o do sistema. Algo entre 50% e 75% da RAM. - **work_mem:** memória de cada ordenação ou agrupamento, por operação e por conexão. Uma consulta complexa usa várias ao mesmo tempo, então 100 conexões com 64 MB podem passar de 6 GB em um pico. Suba com cuidado. - **maintenance_work_mem:** memória de VACUUM e de criação de índices. Um valor maior acelera essas tarefas sem afetar as consultas normais. - **max_connections:** o padrão é 100. Cada conexão é um processo com memória própria, então aumentar para 500 ou 1000 é quase sempre o remédio errado. A solução para muitas conexões é um pooler. | RAM da VPS dedicada ao banco | shared_buffers | effective_cache_size | work_mem | maintenance_work_mem | | --- | --- | --- | --- | --- | | 4 GB | 1GB | 3GB | 8MB | 256MB | | 8 GB | 2GB | 6GB | 16MB | 512MB | | 16 GB | 4GB | 12GB | 32MB | 1GB | | 32 GB | 8GB | 24GB | 64MB | 2GB | Se a aplicação roda na mesma VPS, use a linha correspondente à metade da RAM. Em vez de editar o arquivo principal, crie um arquivo próprio em *conf.d*, que o Ubuntu inclui por padrão. Confirme com `grep include_dir /etc/postgresql/16/main/postgresql.conf`; se a linha não existir, edite os mesmos parâmetros no próprio *postgresql.conf*. ``` # /etc/postgresql/16/main/conf.d/ajustes.conf (VPS de 8 GB só para o banco) shared_buffers = 2GB effective_cache_size = 6GB work_mem = 16MB maintenance_work_mem = 512MB max_connections = 100 random_page_cost = 1.1 sudo systemctl restart postgresql sudo -u postgres psql -c "SHOW shared_buffers;" ``` O *random_page_cost* em 1.1 diz ao planejador que leitura aleatória em NVMe custa quase o mesmo que leitura sequencial, o que o leva a usar índices com mais frequência. Para saber se o *work_mem* está curto, rode uma consulta lenta com `EXPLAIN (ANALYZE, BUFFERS)`: a indicação *external merge Disk* mostra uma ordenação que não coube na memória. ### Quando usar PgBouncer O PgBouncer fica entre a aplicação e o banco e reaproveita poucas conexões reais para atender muitas conexões de clientes. Ele faz sentido quando aparece o erro *sorry, too many clients already*, quando a aplicação abre e fecha conexões o tempo todo, como PHP e funções serverless, ou quando várias instâncias da aplicação somam mais conexões do que o banco aguenta. ``` sudo apt install -y pgbouncer # copie o hash da senha para o arquivo de usuários do PgBouncer sudo -u postgres psql -Atc "SELECT rolpassword FROM pg_authid WHERE rolname = 'meu_usuario'" # /etc/pgbouncer/userlist.txt # cole o valor completo retornado, que começa com SCRAM-SHA-256$4096: "meu_usuario" "VALOR_RETORNADO_PELA_CONSULTA" # /etc/pgbouncer/pgbouncer.ini (ajuste ou acrescente estas linhas) [databases] meu_banco = host=127.0.0.1 port=5432 dbname=meu_banco [pgbouncer] listen_addr = 127.0.0.1 listen_port = 6432 auth_type = scram-sha-256 auth_file = /etc/pgbouncer/userlist.txt pool_mode = transaction max_client_conn = 500 default_pool_size = 20 sudo systemctl restart pgbouncer ``` A aplicação passa a usar a porta 6432 na string de conexão. O modo *transaction* é o que mais economiza conexões, mas quebra recursos que dependem da sessão, como *SET* fora de transação, advisory locks, *LISTEN* e tabelas temporárias. Alguns ORMs têm opção própria para esse cenário, como o parâmetro `pgbouncer=true` do Prisma. Migrações de schema devem continuar indo direto para a porta 5432. ## Backup agendado com pg_dump O `pg_dump` gera uma cópia consistente do banco sem parar o serviço. O formato custom (`-Fc`) sai compactado e permite restaurar tabelas específicas com o `pg_restore`. Crie o script `/usr/local/bin/backup-postgres.sh`: ``` #!/usr/bin/env bash set -euo pipefail DESTINO="/var/backups/postgres" DATA="$(date +%F_%H%M)" mkdir -p "$DESTINO" chmod 700 "$DESTINO" sudo -u postgres pg_dump -Fc meu_banco > "$DESTINO/meu_banco_$DATA.dump" sudo -u postgres pg_dumpall --globals-only > "$DESTINO/globais_$DATA.sql" find "$DESTINO" -type f -mtime +7 -delete ``` O `pg_dumpall --globals-only` salva usuários e permissões, que não vão no dump de um banco. O *find* apaga cópias com mais de sete dias. Torne o script executável e agende no cron do root: ``` sudo chmod 700 /usr/local/bin/backup-postgres.sh sudo crontab -e # todo dia às 3h15 15 3 * * * /usr/local/bin/backup-postgres.sh >> /var/log/backup-postgres.log 2>&1 ``` A sintaxe do agendamento está explicada no guia de [tarefas agendadas com cron](https://streethosting.com.br/guias/vps/configurar-cron-tarefas-agendadas-vps). Backup que fica só na própria VPS some junto com ela, então envie a pasta para um destino externo com o método do guia de [backup automático com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron). E teste a restauração, porque um dump nunca restaurado não prova nada: ``` sudo -u postgres createdb teste_restauracao sudo -u postgres pg_restore -d teste_restauracao /var/backups/postgres/meu_banco_2026-09-28_0315.dump sudo -u postgres psql -d teste_restauracao -c "\dt" sudo -u postgres dropdb teste_restauracao ``` Para restaurar por cima do banco de produção, use `pg_restore --clean --if-exists -d meu_banco arquivo.dump`. O dump diário pode perder até um dia de dados. Se isso é demais para o seu negócio, o próximo passo é arquivar o WAL continuamente com uma ferramenta como o pgBackRest, que permite voltar o banco a qualquer momento. ## Qual VPS usar para PostgreSQL PostgreSQL rende proporcionalmente à RAM disponível para cache e ao número de núcleos para atender conexões simultâneas. Por isso a [VPS Xeon](https://streethosting.com.br/vps/xeon), que entrega mais memória e vCPU por real, é o ponto de partida mais comum: 8 GB com 6 vCPU e 80 GB de NVMe saem por R$ 77,00, 16 GB com 9 vCPU e 160 GB por R$ 145,00 e 32 GB com 15 vCPU e 320 GB por R$ 281,00. Quando o gargalo é o tempo de consultas pesadas, a VPS Ryzen 9 9950X com DDR5 e até 5,7 GHz acelera cada uma, a partir de R$ 126,00 com 4 vCPU e 8 GB. Todos os planos das [VPS da StreetHosting](https://streethosting.com.br/vps) usam NVMe, ficam em São Paulo e têm AntiDDoS e acesso root. O upgrade pelo painel cobra só a diferença proporcional e reinicia a VM; depois dele, ajuste o *shared_buffers* e os demais parâmetros à RAM nova, porque o PostgreSQL não faz isso sozinho. A conta completa de dimensionamento, com tabela por tamanho de banco, está em [como escolher uma VPS para banco de dados](https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados). ## Perguntas frequentes ### PostgreSQL ou MySQL para minha aplicação? PostgreSQL é mais completo para dados complexos, com JSON nativo, tipos avançados e consultas sofisticadas, e é o padrão de frameworks como Django, Rails e boa parte do ecossistema Node.js. MySQL e MariaDB são mais simples e continuam sendo o padrão de plataformas como WordPress. ### Como conectar ao PostgreSQL remotamente? Por padrão o PostgreSQL só escuta localmente. Para acesso remoto, inclua o endereço da própria VPS em listen_addresses no postgresql.conf, adicione no pg_hba.conf uma regra para o IP do cliente com o método SCRAM e libere a porta 5432 no firewall só para esse IP. Para administrar do seu computador, um túnel SSH evita abrir a porta. ### Qual porta o PostgreSQL usa? A porta padrão do PostgreSQL é a 5432. O PgBouncer, quando usado, costuma escutar na 6432. Se precisar de acesso remoto, libere a porta no firewall apenas para os IPs que realmente precisam conectar. ### Como fazer backup do PostgreSQL? Use pg_dump no formato custom, com a opção -Fc, que gera um arquivo compactado restaurável com pg_restore. Agende com cron todos os dias, apague cópias antigas automaticamente, envie os arquivos para fora da VPS e teste a restauração em um banco separado. ### Quanto de shared_buffers usar no PostgreSQL? Em uma VPS dedicada ao banco, o ponto de partida é 25% da RAM, com effective_cache_size entre 50% e 75%. Se a aplicação roda na mesma VPS, reduza proporcionalmente. Depois de mudar shared_buffers é preciso reiniciar o serviço. ## Guias relacionados - [Como escolher VPS para banco de dados: RAM, CPU e NVMe](https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados.md) - [UFW na VPS Ubuntu: regras de firewall sem perder o SSH](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu.md) - [Como configurar backup automático da VPS com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron.md) - [Como instalar e configurar Redis na VPS Ubuntu](https://streethosting.com.br/guias/vps/configurar-redis-vps-ubuntu.md) - [Como instalar MariaDB ou MySQL numa VPS Ubuntu](https://streethosting.com.br/guias/vps/instalar-mariadb-mysql-vps-ubuntu.md) ## Produtos citados - https://streethosting.com.br/vps/xeon - https://streethosting.com.br/vps - https://streethosting.com.br/vps/ryzen ## Dados estruturados ```json [ { "@context": "https://schema.org", "@type": [ "Article", "TechArticle" ], "headline": "PostgreSQL na VPS Ubuntu: acesso seguro, backup e otimização", "name": "Como instalar PostgreSQL na VPS Ubuntu com segurança", "abstract": "PostgreSQL é o banco relacional open source mais completo e o padrão de muitas aplicações modernas. Veja como instalar na VPS Ubuntu, criar usuário e banco para a aplicação, entender a autenticação, liberar acesso remoto sem expor a porta, agendar backups e ajustar a memória.", "description": "Instale o PostgreSQL na VPS Ubuntu, crie usuário e banco, libere acesso remoto só por IP, agende backups com pg_dump e ajuste memória e conexões.", "datePublished": "2026-06-18", "dateModified": "2026-09-28", "author": { "@type": "Organization", "name": "Equipe StreetHosting" }, "publisher": { "@type": "Organization", "name": "StreetHosting", "url": "https://streethosting.com.br" }, "inLanguage": "pt-BR", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://streethosting.com.br/guias/vps/instalar-postgresql-vps-ubuntu" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "PostgreSQL ou MySQL para minha aplicação?", "acceptedAnswer": { "@type": "Answer", "text": "PostgreSQL é mais completo para dados complexos, com JSON nativo, tipos avançados e consultas sofisticadas, e é o padrão de frameworks como Django, Rails e boa parte do ecossistema Node.js. MySQL e MariaDB são mais simples e continuam sendo o padrão de plataformas como WordPress." } }, { "@type": "Question", "name": "Como conectar ao PostgreSQL remotamente?", "acceptedAnswer": { "@type": "Answer", "text": "Por padrão o PostgreSQL só escuta localmente. Para acesso remoto, inclua o endereço da própria VPS em listen_addresses no postgresql.conf, adicione no pg_hba.conf uma regra para o IP do cliente com o método SCRAM e libere a porta 5432 no firewall só para esse IP. Para administrar do seu computador, um túnel SSH evita abrir a porta." } }, { "@type": "Question", "name": "Qual porta o PostgreSQL usa?", "acceptedAnswer": { "@type": "Answer", "text": "A porta padrão do PostgreSQL é a 5432. O PgBouncer, quando usado, costuma escutar na 6432. Se precisar de acesso remoto, libere a porta no firewall apenas para os IPs que realmente precisam conectar." } }, { "@type": "Question", "name": "Como fazer backup do PostgreSQL?", "acceptedAnswer": { "@type": "Answer", "text": "Use pg_dump no formato custom, com a opção -Fc, que gera um arquivo compactado restaurável com pg_restore. Agende com cron todos os dias, apague cópias antigas automaticamente, envie os arquivos para fora da VPS e teste a restauração em um banco separado." } }, { "@type": "Question", "name": "Quanto de shared_buffers usar no PostgreSQL?", "acceptedAnswer": { "@type": "Answer", "text": "Em uma VPS dedicada ao banco, o ponto de partida é 25% da RAM, com effective_cache_size entre 50% e 75%. Se a aplicação roda na mesma VPS, reduza proporcionalmente. Depois de mudar shared_buffers é preciso reiniciar o serviço." } } ] } ] ```