Implementando postgres_fdw no PostgreSQL
19 de agosto de 2025 557 Views

Implementando postgres_fdw no PostgreSQL

Introdução

O postgres_fdw (Foreign Data Wrapper) é uma extensão oficial do PostgreSQL que permite acessar e manipular dados armazenados em servidores PostgreSQL externos como se fossem tabelas locais. Esta extensão implementa o padrão SQL/MED (Management of External Data) e oferece uma maneira eficiente de integrar dados de múltiplos bancos de dados PostgreSQL sem a necessidade de replicação ou ETL complexo.

Níveis de Isolamento no PostgreSQL e o papel do postgres_fdw

No PostgreSQL, os bancos de dados dentro de um cluster são isolados uns dos outros por design. Este isolamento oferece segurança e separação lógica entre aplicações, mas também cria desafios quando é necessário acessar dados em diferentes bancos de dados:

  1. Isolamento por Design: Diferentemente de outros SGBDs, o PostgreSQL mantém cada banco de dados como uma entidade completamente separada. Não é possível executar consultas entre bancos de dados usando sintaxe como SELECT * FROM banco1.schema.tabela.
  2. Separação de Usuários e Permissões: Cada banco de dados possui seu próprio conjunto de usuários, roles e permissões, o que dificulta o acesso unificado.
  3. Schemas vs. Bancos de Dados: Enquanto schemas dentro de um banco de dados permitem organização lógica com acesso transparente, bancos de dados diferentes são completamente isolados.

O postgres_fdw surge como uma solução elegante para esse desafio, permitindo que os dados atravessem essa barreira de isolamento. Ele estabelece uma ponte entre bancos de dados não apenas no mesmo servidor, mas também entre diferentes instâncias de PostgreSQL em servidores distintos, mantendo a integridade do modelo de segurança e isolamento original.

Este wrapper permite que organizações implementem arquiteturas de microserviços com bancos de dados isolados, ao mesmo tempo em que mantém a capacidade de executar consultas integradas quando necessário. Isso é particularmente valioso em ambientes onde:

  • Diferentes equipes ou departamentos mantêm seus próprios bancos de dados

  • Requisitos de conformidade exigem separação física de dados

  • Existe a necessidade de integrar sistemas legados com novas aplicações

  • A escalabilidade horizontal é implementada através da fragmentação de bancos de dados

Este tutorial guiará você pelos passos necessários para configurar e utilizar o postgres_fdw em seu ambiente PostgreSQL, permitindo consultas transparentes entre diferentes instâncias do banco de dados.

Pré-requisitos

  • PostgreSQL 9.3 ou superior instalado (recomenda-se a versão mais recente)

  • Acesso administrativo aos bancos de dados de origem e destino

  • Conectividade de rede entre os servidores PostgreSQL

  • Credenciais de acesso para os bancos de dados remotos

Passos para Implementação

Passo 1: Instalar a extensão postgres_fdw

Primeiro, você precisa instalar a extensão no banco de dados onde deseja acessar as tabelas remotas:

— Conecte-se ao banco de dados local

\c banco_de_dados_local

— Crie a extensão

CREATE
EXTENSION postgres_fdw;

Verifique se a extensão foi instalada corretamente:

\dx

Você deve ver postgres_fdw na lista de extensões instaladas.

Passo 2: Criar o servidor externo

Agora, crie um servidor externo que representa a instância remota do PostgreSQL:

CREATE SERVER servidor_remoto
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host ‘endereco_do_servidor_remoto’,
port ‘5432’,
dbname ‘banco_de_dados_remoto’);

Substitua: – servidor_remoto pelo nome que você deseja dar ao servidor – endereco_do_servidor_remoto pelo endereço IP ou hostname do servidor remoto – banco_de_dados_remoto pelo nome do banco de dados remoto que você deseja acessar

Passo 3: Criar mapeamento de usuário

Para autenticar no servidor remoto, você precisa criar um mapeamento de usuário:

CREATE USER MAPPING FOR usuario_local
SERVER servidor_remoto
OPTIONS (user ‘usuario_remoto’, password ‘senha_remota’);

Substitua: – usuario_local pelo usuário PostgreSQL local – usuario_remoto pelo usuário no servidor remoto – senha_remota pela senha do usuário remoto

Para maior segurança, você pode usar:

CREATE USER MAPPING FOR CURRENT_USER
SERVER servidor_remoto
OPTIONS (user ‘usuario_remoto’, password ‘senha_remota’);

Passo 4: Criar esquema para tabelas externas (opcional)

Por organização, você pode criar um esquema específico para as tabelas externas:

CREATE SCHEMA dados_externos;

Passo 5: Importar tabelas estrangeiras

Existem duas maneiras de importar tabelas remotas:

Opção 1: Importar manualmente

CREATE FOREIGN TABLE dados_externos.clientes (
id integer NOT NULL,
nome varchar(100) NOT NULL,
email varchar(100),
data_cadastro date
)
SERVER servidor_remoto
OPTIONS (schema_name ‘public’, table_name ‘clientes’);

Opção 2: Importar automaticamente (recomendado)

IMPORT FOREIGN SCHEMA public
LIMIT TO (clientes, pedidos)
FROM SERVER servidor_remoto
INTO dados_externos;

Para importar todas as tabelas de um esquema:

IMPORT FOREIGN SCHEMA public
FROM SERVER servidor_remoto
INTO dados_externos;

 Passo 6: Conceder permissões nas tabelas externas

GRANT USAGE ON SCHEMA dados_externos TO usuario_aplicacao;
GRANT SELECT, INSERT, UPDATE, DELETE ON dados_externos.clientes TO usuario_aplicacao;

Passo 7: Testar o acesso às tabelas externas

— Verificar tabelas externas disponíveis

SELECT * FROM dados_externos.clientes LIMIT 10;

— Executar uma consulta que une tabelas locais e remotas

SELECT l.id_venda, l.data_venda, r.nome as cliente
FROM vendas l
JOIN dados_externos.clientes r ON l.id_cliente = r.id
LIMIT 10;

Passo 8: Ajustar configurações de desempenho (opcional)

Para melhorar o desempenho, você pode ajustar as opções do FDW:

— Alterar configurações de uma tabela estrangeira

ALTER FOREIGN TABLE dados_externos.clientes
OPTIONS (ADD use_remote_estimate ‘true’);

— Configurar busca em lotes

ALTER SERVER servidor_remoto
OPTIONS (ADD fetch_size ‘1000’);

Monitoramento e Manutenção

Verificar estatísticas de uso

— Verificar estatísticas de execução se estiver usando PostgreSQL 14+

SELECT * FROM pg_stat_foreign_tables
WHERE relname = ‘clientes’;

Atualizar estrutura da tabela se mudanças ocorrerem no remoto

IMPORT FOREIGN SCHEMA public LIMIT TO (clientes)
FROM SERVER servidor_remoto
INTO dados_externos
OPTIONS (import_default ‘true’);

Conclusão: Prós e Contras do postgres_fdw

Prós

  1. Integração Nativa: Implementado e mantido pela comunidade PostgreSQL, garantindo compatibilidade e suporte de longo prazo.
  2. Transparência: Permite acessar tabelas remotas como se fossem locais, com suporte completo para SQL incluindo JOINs complexos.
  3. Desempenho: Executa parte do processamento no servidor remoto, reduzindo a transferência de dados pela rede.
  4. Transações: Suporta transações distribuídas (a partir do PostgreSQL 11), mantendo a integridade dos dados.
  5. Segurança: Fornece controle de acesso granular e suporte para SSL para conexões seguras.
  6. Atualidade dos Dados: Sempre acessa os dados mais recentes, sem latência de replicação.
  7. Filtragem Eficiente: Envia condições WHERE e JOINs para o servidor remoto, minimizando a transferência de dados.
  8. Baixo Impacto de Armazenamento: Não duplica os dados, economizando espaço em disco.

Contras

  1. Dependência de Rede: Requer conectividade constante e estável; problemas de rede afetam diretamente o desempenho e a disponibilidade.
  2. Latência: Pode ser mais lento que acessar tabelas locais, especialmente com muitas consultas pequenas ou alta latência de rede.
  3. Recursos Limitados: Algumas funcionalidades avançadas do PostgreSQL podem não funcionar completamente com tabelas estrangeiras.
  4. Complexidade de Manutenção: Alterações nos esquemas remotos podem exigir atualizações manuais nas definições de tabelas estrangeiras.
  5. Dependência de Disponibilidade: Se o servidor remoto estiver indisponível, as tabelas estrangeiras ficam inacessíveis.
  6. Segurança de Credenciais: As senhas podem estar expostas nas definições de mapeamento de usuário se não forem gerenciadas adequadamente.
  7. Limitações em Índices: Não é possível criar índices locais em tabelas estrangeiras, limitando a otimização de consultas complexas.
  8. Administração Adicional: Requer configuração e monitoramento adicionais em comparação com soluções de replicação automática.

O postgres_fdw é uma solução excelente para federação de dados em ambientes PostgreSQL, especialmente quando você precisa de acesso em tempo real a dados dispersos sem duplicação. No entanto, para cenários com alta disponibilidade ou onde a latência de rede é uma preocupação, outras soluções como replicação lógica podem ser mais adequadas.

Anterior IA para maiores - Quer IA avançada? Comece limpando a bagunça!
Próxima Zero Trust na Prática: A Nova Fronteira da Segurança Corporativa
Tags 4linuxBanco de DadosDesenvolvimentofederação de dadosotimizaçãopostgres_fdwPostgreSQLSQL
Categoria Banco de Dados

About author

Almeida Robson
Almeida Robson 4 posts

Administrador de Bancos de Dados com foco em PostgreSQL, Pai, amante da música, games e tecnologia.

View all posts by this author →

Você pode gostar também

Banco de Dados

Cresce demanda por especialistas em banco de dados noSQL: 4Linux lança curso de MongoDB

Big Data e noSQL caminham juntos e com o crescimento de ‘analytics’ nas grandes corporações a busca por profissionais especialista em banco de dados noSQL aumentou na mesma proporção. Além

Entenda a LGPD e como ela impacta a segurança dos seus dados
Desenvolvimento

Entenda a LGPD e como ela impacta a segurança dos seus dados

LGPD Em 2018, o Brasil adotou a LGPD (Lei Geral de Proteção de dados Pessoais – LGPD/LGPDP), assim como diversos outros países (os EUA, a CCPA e a União Europeia,

Infraestrutura TI

Entenda o Log Binário do MySQL e suas aplicações práticas

O log binário do MySQL é, por vezes, mal compreendido, principalmente por usuários de outros bancos de dados. Nesta postagem pretendo abordar alguns aspectos desse importante mecanismo. Write-ahead logging? Também