Segurança, usuários, privilégios, backup e recuperação

Um banco pode estar disponível e íntegro, mas ainda inseguro: uma credencial compartilhada concede privilégios excessivos; uma conexão aceita tráfego sem proteção; um backup contém todos os dados e fica exposto; ou uma cópia concluída nunca consegue ser restaurada.

Segurança e recuperação não são etapas adicionadas depois do esquema. Elas formam uma cadeia: reduzir exposição, autenticar a origem, autorizar somente ações necessárias, proteger dados e segredos, registrar sinais úteis, criar cópias coerentes e comprovar que a restauração atende ao negócio.

Esta aula é específica para a operação de bancos PostgreSQL. Os princípios organizacionais de controle de acesso e menor privilégio e de backup, continuidade e recuperação de desastres permanecem aprofundados na trilha de Segurança da Informação.

Ao final, você deverá conseguir:

• separar exposição de rede, autenticação, autorização e proteção criptográfica;
• explicar o modelo de papéis do PostgreSQL;
• agrupar privilégios em papéis sem login e concedê-los a identidades rastreáveis;
• aplicar menor privilégio em banco, schema, tabela, sequência e função;
• entender limites de ownership, superusuário, PUBLIC, privilégios padrão e RLS;
• tratar credenciais como segredos com ciclo de vida;
• diferenciar dump lógico, backup físico, arquivamento de WAL, réplica e snapshot;
• relacionar RPO e RTO à frequência e à arquitetura de backup;
• planejar recuperação pontual sem perder a cadeia de WAL necessária;
• validar integridade, restauração, dados, permissões e tempo de recuperação;
• reconhecer que uma cópia não testada é apenas uma possibilidade de backup.

Segurança do banco é uma cadeia de decisões

Quatro perguntas ajudam a localizar responsabilidades:

1. A conexão pode chegar ao servidor? Rede, firewall, interfaces de escuta e regras de origem reduzem a superfície.
2. Quem está tentando entrar? A autenticação valida uma identidade por senha, certificado, integração externa ou mecanismo local.
3. O que essa identidade pode fazer? Papéis, ownership, grants, policies e contexto determinam a autorização.
4. Como dados e credenciais são protegidos? TLS, armazenamento, gestão de segredos, logs e backups cobrem canais e cópias diferentes.

Essas camadas não se substituem. TLS protege o tráfego, mas não corrige GRANT ALL. Um firewall reduz origens alcançáveis, mas não impede uma aplicação autorizada de executar SQL vulnerável. Uma senha forte não limita o dano de um papel superusuário.

Reduza a exposição antes de aceitar credenciais

O servidor deve escutar somente nas interfaces necessárias, e a rede deve permitir apenas origens previstas. Publicar diretamente a porta do banco para toda a Internet e depender apenas de senha amplia tentativas, falhas de configuração e impacto de credenciais vazadas.

No PostgreSQL, o pg_hba.conf seleciona a regra de autenticação conforme tipo de conexão, banco, papel e endereço. A primeira regra correspondente é usada; se a autenticação falhar, o servidor não tenta uma regra posterior.

Exemplo conceitual:

hostssl  guiaestudos  app_runtime  10.20.4.0/24  scram-sha-256
hostssl  guiaestudos  dba_oncall   10.20.8.0/24  scram-sha-256

As redes são ilustrativas. Em uma implantação real, valide a ordem, o método suportado e os endereços corretos. A view pg_hba_file_rules ajuda a identificar linhas inválidas antes ou depois do reload:

SELECT line_number, type, database, user_name, address, auth_method, error
FROM pg_hba_file_rules
ORDER BY line_number;

TLS protege a conexão, não a autorização

O PostgreSQL oferece conexões TLS — ainda chamadas de SSL em parâmetros e documentação — para proteger o tráfego cliente-servidor. Habilitar TLS no servidor não garante sozinho que todos os clientes o usarão nem que verificarão corretamente a identidade do servidor.

Combine:

• regras hostssl quando o transporte protegido é obrigatório;
• certificado e chave com permissões adequadas;
• cliente configurado para verificar certificado e nome do servidor;
• rotação e monitoramento de validade;
• proibição de downgrade silencioso na política da aplicação.

Criptografia em trânsito não cifra automaticamente arquivos de dados, dumps, WAL arquivado ou logs. Proteção em repouso depende da plataforma, do armazenamento, do gerenciador de chaves e da arquitetura escolhida.

PostgreSQL usa papéis para login e agrupamento

No PostgreSQL, não existe uma separação estrutural entre “usuário” e “grupo”: ambos são roles. O atributo LOGIN determina se o papel pode iniciar uma sessão.

Uma organização simples separa capacidades de identidades:

CREATE ROLE guia_leitura NOLOGIN;
CREATE ROLE guia_escrita NOLOGIN;

CREATE ROLE app_runtime
  LOGIN
  NOSUPERUSER
  NOCREATEDB
  NOCREATEROLE;

GRANT guia_leitura TO app_runtime;
GRANT guia_escrita TO app_runtime;

guia_leitura e guia_escrita representam conjuntos de permissão. app_runtime é a identidade usada pela aplicação e recebe memberships. Essa separação facilita revisar “quem possui qual capacidade” sem repetir grants objeto por objeto para cada login.

Identidade compartilhada reduz rastreabilidade

Pessoas administradoras devem ter identidades individuais, elevando privilégios por processo controlado quando necessário. Aplicações e automações usam identidades próprias por serviço e ambiente.

Uma única conta “admin” compartilhada cria problemas:

• não identifica quem realizou a ação;
• dificulta revogar apenas uma pessoa ou sistema;
• incentiva guardar o segredo em vários lugares;
• mistura acesso humano, aplicação e manutenção;
• amplia o impacto de um vazamento.

O nome da role não prova a pessoa real; autenticação externa, gestão de acesso e logs também participam da atribuição.

Superusuário não é um papel normal da aplicação

Superusuários ignoram praticamente todas as verificações de permissão, exceto o direito de login. Uma aplicação comum não deve usar esse atributo. CREATEDB, CREATEROLE, REPLICATION e BYPASSRLS também são capacidades poderosas e precisam de justificativa própria.

Papéis predefinidos, como os de leitura de estatísticas ou manutenção, podem evitar superusuário em certas tarefas. Seus poderes podem evoluir entre versões; revise a documentação e os release notes antes de tratá-los como contrato eterno.

Privilégios precisam seguir o caminho até o objeto

Para consultar app.conteudo, uma role pode precisar de:

• CONNECT no banco;
• USAGE no schema app;
• SELECT na tabela;
• permissões em sequências ou funções quando a operação as utiliza;
• uma policy compatível, se Row-Level Security estiver ativa.

Exemplo:

GRANT CONNECT ON DATABASE guiaestudos TO guia_leitura;
GRANT USAGE ON SCHEMA app TO guia_leitura;
GRANT SELECT ON TABLE app.trilha, app.conteudo TO guia_leitura;

GRANT INSERT, UPDATE ON TABLE app.matricula TO guia_escrita;
GRANT USAGE, SELECT ON SEQUENCE app.matricula_matricula_id_seq TO guia_escrita;

Conceder INSERT na tabela não concede necessariamente uso da sequência que produz um identificador. Por outro lado, USAGE no schema permite referenciar objetos, mas não entrega automaticamente acesso às tabelas.

Ownership é uma capacidade poderosa

O proprietário controla o objeto e possui poderes implícitos para alterá-lo ou descartá-lo. Um desenho robusto costuma usar um papel de ownership sem login para migrações e outro papel limitado para a aplicação em execução.

CREATE ROLE guia_owner NOLOGIN;
CREATE ROLE guia_migrator LOGIN;

GRANT guia_owner TO guia_migrator;

A forma exata de usar ou assumir o papel depende das opções de membership e da versão do PostgreSQL. O ponto arquitetural é não tornar a identidade diária da aplicação dona de todas as tabelas.

PUBLIC representa todas as roles

PUBLIC é um grupo implícito. Alguns objetos podem receber privilégios padrão para PUBLIC, dependendo do tipo e da versão. Revise explicitamente banco, schemas, funções e demais objetos relevantes, em vez de presumir que “não concedi, então ninguém acessa”.

Revogações precisam considerar impacto:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

Esse comando é apenas exemplo. Em versões atuais, o ownership e os defaults do schema public dependem de como o banco foi criado ou atualizado. Inspecione o ambiente antes de alterar uma base existente.

Privilégios padrão cobrem objetos futuros

Grants sobre “todas as tabelas atuais” não alcançam automaticamente as próximas tabelas. ALTER DEFAULT PRIVILEGES define o que será aplicado aos objetos futuros criados por uma role específica:

ALTER DEFAULT PRIVILEGES
FOR ROLE guia_owner
IN SCHEMA app
GRANT SELECT ON TABLES TO guia_leitura;

O detalhe crítico é quem criará o objeto. Configurar os defaults de guia_owner não afeta tabelas criadas por outra role. Teste o fluxo real de migração.

Row-Level Security filtra linhas, mas exige modelo cuidadoso

Grants atuam no nível de objeto e, em alguns casos, coluna. Row-Level Security (RLS) adiciona policies que controlam quais linhas podem ser lidas ou modificadas.

ALTER TABLE app.matricula ENABLE ROW LEVEL SECURITY;

CREATE POLICY matricula_por_estudante
ON app.matricula
FOR SELECT
USING (estudante_id = current_setting('app.estudante_id')::bigint);

O exemplo depende de a aplicação configurar o contexto corretamente e impedir que o usuário o manipule. Uma policy incompleta pode vazar linhas ou bloquear operações legítimas.

Pontos importantes no PostgreSQL:

• quando RLS está habilitada e não há policy aplicável, prevalece negação por padrão;
• superusuários e roles com BYPASSRLS ignoram RLS;
• proprietários normalmente ignoram policies, salvo uso apropriado de FORCE ROW LEVEL SECURITY e exceções documentadas;
• USING controla visibilidade/linhas existentes; WITH CHECK controla quais novas versões podem ser criadas;
• RLS não substitui grants: a role ainda precisa de privilégio no objeto.

Teste policies com cada papel efetivo e operação, incluindo joins, funções, importações, manutenção e tratamento de NULL.

A aplicação também precisa reduzir a autoridade do SQL

Parâmetros devem transportar valores, não trechos de comando:

SELECT conteudo_id, titulo
FROM app.conteudo
WHERE slug = $1;

Consultas parametrizadas reduzem injeção em valores. Nomes de tabela, coluna e direção de ordenação não viram parâmetros comuns; quando precisam ser dinâmicos, selecione-os por allowlist e composição segura da biblioteca.

Menor privilégio limita o impacto se uma injeção ocorrer, mas não corrige a vulnerabilidade. Uma role com apenas SELECT ainda pode expor todos os dados que consegue ler.

Funções SECURITY DEFINER executam com poderes do proprietário e criam uma fronteira delicada. Use somente quando necessário, fixe um search_path seguro, qualifique objetos, restrinja EXECUTE e revise SQL dinâmico. Caso contrário, uma função criada para limitar acesso pode se tornar caminho de elevação.

Credenciais são segredos com ciclo de vida

Não coloque senhas em código, imagem, repositório, exemplo real, histórico do shell ou log. Use o mecanismo de segredos da plataforma e conceda leitura apenas ao processo necessário.

O ciclo inclui:

1. geração com entropia adequada;
2. distribuição por canal protegido;
3. armazenamento controlado;
4. uso sem exposição em mensagens e métricas;
5. rotação planejada sem indisponibilidade;
6. revogação quando identidade ou serviço termina;
7. resposta e investigação diante de suspeita de vazamento.

Rotação não é só trocar uma string. Pools mantêm conexões antigas; aplicações precisam obter o novo segredo, abrir novas sessões e encerrar as anteriores. Tenha procedimento testado para coexistência curta ou troca coordenada.

Logs de conexões e comandos ajudam na operação, mas podem registrar SQL, endereços, nomes e valores sensíveis. Defina finalidade, acesso, retenção e mascaramento. Mais log não significa automaticamente mais segurança.

Backup precisa corresponder ao tipo de recuperação

Há três famílias nativas importantes no PostgreSQL.

Nenhuma estratégia é “melhor” fora do requisito. Muitas arquiteturas combinam dump lógico para flexibilidade com backup físico e WAL para RPO/RTO mais rigorosos.

Dump lógico reconstrói objetos e dados

pg_dump cria uma visão consistente de um banco mesmo enquanto ele é usado e não bloqueia leitores ou escritores comuns. Formatos custom e directory são restaurados por pg_restore e permitem seleção e paralelismo.

pg_dump --format=custom --file=guiaestudos.dump guiaestudos
pg_restore --list guiaestudos.dump

Não copie os comandos com credenciais na linha. O mecanismo de autenticação deve estar configurado de forma segura.

pg_dump trabalha com um banco. Objetos globais do cluster, como roles e tablespaces, não estão contidos nesse dump; pg_dumpall --globals-only pode exportá-los, exigindo proteção adicional porque definições de roles são sensíveis.

Um dump lógico é útil para migração e restauração seletiva, mas a restauração recria objetos e carrega dados. Em bases grandes, isso pode não atender ao RTO.

Backup físico preserva o cluster

pg_basebackup copia um cluster em execução e pode ser base para recuperação física ou standby. Ele não seleciona uma tabela isolada. A restauração precisa respeitar compatibilidade, tablespaces, permissões, configuração e WAL requerido.

Um snapshot de volume só é backup válido quando o procedimento garante consistência do conjunto, inclui todos os volumes/tablespaces necessários e existe fora do mesmo destino de falha. Uma fotografia instantânea propagada ou apagada junto com a origem pode ser apenas conveniência operacional.

Réplica não substitui cópia histórica independente

Replicação melhora disponibilidade e pode reduzir tempo de retorno, mas também propaga DELETE, corrupção lógica e mudanças indevidas. Um atacante ou erro com acesso suficiente pode atingir origem e réplica.

Use réplicas e backups como controles complementares:

• réplica para continuidade e failover conforme arquitetura;
• backup versionado e separado para retornar a estados anteriores;
• dump lógico quando recuperação seletiva ou portabilidade é importante;
• WAL arquivado para reduzir perda entre base backups e escolher ponto temporal.

PITR combina base backup e uma cadeia contínua de WAL

O Write-Ahead Log registra mudanças necessárias à recuperação. Com um base backup e todos os segmentos de WAL requeridos, o PostgreSQL pode reproduzir alterações até um ponto escolhido.

Imagine:

• base backup concluído às 00:00;
• WAL arquivado continuamente;
• exclusão indevida às 14:32;
• último estado válido identificado às 14:31:50.

A recuperação prepara uma cópia do base backup, configura a origem dos WALs e o alvo temporal, inicia o servidor em recuperação e valida o novo estado. Ela não desfaz apenas uma transação na instância original.

Se faltar um segmento necessário, a cadeia se rompe. Monitorar apenas “o último backup base terminou” ignora falhas no archive_command, atraso, retenção incorreta ou armazenamento indisponível.

Arquivamento WAL não inclui automaticamente alterações manuais em postgresql.conf, pg_hba.conf e pg_ident.conf. Configurações, certificados, automações e documentação de infraestrutura precisam de proteção e versionamento próprios, sem expor segredos.

RPO e RTO transformam impacto em requisito técnico

• RPO (Recovery Point Objective) limita quanta perda de dados, medida no tempo, é tolerável.
• RTO (Recovery Time Objective) limita quanto tempo o serviço pode levar para voltar ao nível acordado.

Um dump diário pode implicar até quase 24 horas de perda, caso seja a única cópia. Guardar WAL com baixa latência pode reduzir o RPO, mas não garante RTO curto: restaurar terabytes e reproduzir longa sequência ainda leva tempo.

Defina também:

• escopo de dados e dependências;
• retenção e pontos históricos necessários;
• região ou domínio de falha alternativo;
• tempo para detectar, decidir e obter autorização;
• capacidade de infraestrutura no ambiente de recuperação;
• critérios de integridade e liberação ao usuário;
• procedimento de retorno ou nova linha do tempo.

RPO/RTO não devem ser prometidos pela equipe de banco isoladamente; precisam refletir impacto e capacidade testada.

A cópia precisa sobreviver ao mesmo incidente

Backups contêm dados valiosos e podem ser alvo direto. A estratégia deve avaliar:

• separação de contas, credenciais e domínios administrativos;
• cópias versionadas, offline ou imutáveis conforme o risco;
• criptografia em trânsito e repouso;
• gestão e recuperação das chaves de criptografia;
• acesso mínimo para criar, ler, apagar e alterar retenção;
• proteção contra exclusão em massa;
• inventário de base backups, incrementais e WAL dependentes;
• eliminação segura ao fim da retenção.

Criptografar e perder a chave torna a cópia indisponível. Guardar a chave junto da cópia com o mesmo controle reduz a separação. O plano deve recuperar dados e os meios autorizados para decifrá-los.

Backups incrementais do PostgreSQL atual dependem de backups anteriores e WAL summaries; a ferramenta não decide sozinha quais ancestrais ainda são necessários. Não remova uma base da cadeia sem comprovar que nenhum incremental retido depende dela.

Verificar arquivo não substitui restaurar

pg_verifybackup verifica o manifesto de um base backup produzido por pg_basebackup, compara arquivos e pode analisar WAL necessário ao backup. Isso detecta problemas importantes, mas a própria documentação alerta que a verificação não substitui testes de restauração.

Um teste completo deve:

1. selecionar uma cópia segundo o inventário real;
2. provisionar ambiente isolado e compatível;
3. recuperar segredos e chaves pelo procedimento aprovado;
4. restaurar base, dumps, globais, configurações e WAL necessários;
5. iniciar sem conectar clientes de produção;
6. validar logs, catálogo, constraints e objetos esperados;
7. executar verificações de negócio e amostras reconciliáveis;
8. confirmar papéis, ownership, grants e RLS;
9. medir RPO e cada etapa do RTO;
10. registrar lacunas, responsáveis e novo teste.

Um comando que termina com código zero não comprova que o serviço voltou corretamente. Pode faltar extensão, role, chave, arquivo de configuração, objeto global ou integração externa.

Restaure em ambiente isolado

Uma cópia restaurada contém dados reais. A rede, os acessos e a retenção do teste devem ser protegidos. Desative integrações que possam enviar e-mails, cobrar, publicar eventos ou conectar consumidores de produção.

Ao restaurar dump lógico, revise ownership e privilégios. Opções como --no-owner e --no-acl mudam o resultado e só devem ser usadas quando o processo recria essas definições deliberadamente.

Validação de negócio fecha a recuperação

Exemplos úteis para o Guia Estudos:

• quantidade de trilhas publicadas por área;
• conteúdos sem módulo ou com ordem duplicada;
• matrículas apontando para trilhas inexistentes;
• datas máximas esperadas antes do alvo de PITR;
• amostras por identificador conhecido;
• capacidade de leitura pelo papel da aplicação e negação para papéis indevidos.

Constraints ajudam a detectar estados impossíveis, como vimos em integridade de entidade, referencial e regras de negócio, mas não provam que todos os fatos esperados foram recuperados.

Mudanças de acesso e recuperação precisam de procedimento

Uma revisão periódica deve responder:

• quais roles têm LOGIN, superusuário ou atributos especiais?
• quem é membro de cada papel privilegiado?
• quais objetos são propriedade de identidades humanas ou da aplicação?
• quais grants existem para PUBLIC?
• privilégios padrão correspondem ao criador real das migrações?
• há contas sem uso, credenciais vencidas ou acessos emergenciais abertos?
• RLS está habilitada e testada sob o papel efetivo?
• backups e WAL cumprem retenção, RPO e separação?
• qual foi o último restore completo dentro do RTO?

Exemplo de inventário inicial, sem expor hashes de senha:

SELECT
  rolname,
  rolcanlogin,
  rolsuper,
  rolcreatedb,
  rolcreaterole,
  rolreplication,
  rolbypassrls
FROM pg_roles
ORDER BY rolname;

Não automatize revogação apenas por um contador ou data sem entender jobs raros e acessos de emergência. A revisão precisa de proprietário, evidência e plano de rollback.

Erros comuns

• expor a porta do banco amplamente e confiar na senha: aumenta superfície e impacto de vazamento;
• ordenar o pg_hba.conf do geral para o específico: a primeira correspondência pode capturar conexões indevidamente;
• confundir autenticação com autorização: login aceito não define o que deveria ser permitido;
• habilitar TLS sem exigir e verificar no cliente: o canal pode não ter a garantia esperada;
• usar superusuário na aplicação: qualquer falha recebe poder quase irrestrito;
• misturar ownership e runtime: a aplicação pode alterar ou remover estruturas que só a migração deveria controlar;
• compartilhar conta administrativa: rastreabilidade e revogação ficam comprometidas;
• conceder ALL por conveniência: privilégios sem necessidade permanecem depois da urgência;
• ignorar schema, sequência e função: a autorização real atravessa vários tipos de objeto;
• configurar default privileges para a role errada: objetos futuros nascem com grants inesperados;
• tratar RLS como substituta de grants: as duas camadas são necessárias;
• testar RLS como proprietário ou superusuário: o resultado pode contornar policies;
• concatenar entrada em SQL: menor privilégio reduz impacto, mas não corrige injeção;
• guardar senha em URI registrada ou repositório: o segredo se espalha por logs e histórico;
• chamar réplica de backup: exclusão e corrupção lógica podem ser replicadas;
• ter apenas cópia no mesmo domínio de falha: o incidente pode remover origem e backup;
• confundir pg_dump com backup físico: unidades e formas de restauração são diferentes;
• arquivar WAL sem monitorar continuidade: um único segmento ausente pode impedir o alvo;
• apagar backup ancestral de incremental: a cadeia restante pode ficar inutilizável;
• verificar checksum e não restaurar: integridade do arquivo não comprova serviço recuperável;
• restaurar teste conectado à produção: efeitos externos e exposição de dados podem ocorrer;
• medir somente tempo de cópia: RTO inclui decisão, provisão, restauração, validação e liberação;
• não recuperar roles e configurações: dados voltam, mas aplicação não opera corretamente.

Checklist de segurança e recuperação

1. O servidor escuta apenas nas interfaces necessárias?
2. Firewall e rede limitam origens e ambientes?
3. As regras do pg_hba.conf foram revisadas na ordem e validadas?
4. TLS é exigido e a identidade do servidor é verificada pelo cliente?
5. Cada pessoa, aplicação e automação possui identidade própria?
6. Papéis de capacidade são separados de papéis com login?
7. A aplicação executa sem superusuário, ownership e atributos especiais?
8. Grants cobrem somente banco, schema, objetos e operações necessários?
9. PUBLIC, ownership e default privileges foram inventariados?
10. RLS foi testada como papel efetivo para leitura e escrita?
11. SQL dinâmico usa parâmetros ou allowlists apropriadas?
12. Segredos ficam fora de código, logs e comandos compartilhados?
13. Rotação e revogação foram testadas com pools de conexão?
14. Logs têm acesso, retenção e conteúdo compatíveis com o risco?
15. O tipo de backup corresponde ao escopo de restauração?
16. Objetos globais, configurações, extensões e chaves estão incluídos no plano?
17. Réplicas e snapshots são tratados separadamente de cópias históricas?
18. Base backups e todos os WALs necessários são monitorados?
19. Incrementais mantêm ancestrais e manifestos requeridos?
20. Backups estão separados e protegidos contra alteração e exclusão?
21. RPO e RTO são definidos pelo impacto e comprovados por teste?
22. A restauração ocorre periodicamente em ambiente isolado?
23. Validações técnicas e de negócio confirmam o estado recuperado?
24. Grants, ownership e RLS são conferidos após o restore?
25. Evidências do teste geram correções com responsável e prazo?

O que você deve guardar

Segurança de banco combina camadas: a rede limita quem chega; a autenticação confirma uma identidade; papéis e privilégios delimitam ações; TLS protege o transporte; segredos e logs exigem governança; backups preservam possibilidades de recuperação.

Dump lógico, backup físico e PITR resolvem necessidades diferentes. Réplica não é cópia histórica, arquivo verificado não é restauração comprovada e backup inacessível por falta de chave não atende à disponibilidade.

Na última aula da trilha, compararemos bancos relacionais e NoSQL a partir de modelo, consultas, consistência, escala e operação — sem escolher tecnologia por moda.

Referências

• PostgreSQL Global Development Group — Client Authentication. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — The pg_hba.conf File. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Secure TCP/IP Connections with SSL. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Database Roles. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Role Membership. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Privileges. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Row Security Policies. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — SQL Dump. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — pg_dump. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — pg_restore. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — pg_basebackup. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — Continuous Archiving and Point-in-Time Recovery. Acesso em 30 ago. 2026.
• PostgreSQL Global Development Group — pg_verifybackup. Acesso em 30 ago. 2026.