PostgreSQL para o Google Sheets: 4 formas de conectar

Levar dados do PostgreSQL para o Google Sheets se resume a 4 caminhos: exportação manual em CSV, Apps Script com JDBC, um conector ETL de terceiros ou consulta direta ao Postgres via DuckDB. Se você precisa dos dados uma única vez, o CSV resolve. Se precisa toda semana - ou se os analistas vivem pedindo para "atualizar os números" - você vai precisar de uma das outras três opções.

A maioria das equipes começa com exportações em CSV e fica nisso por mais tempo do que deveria. Até o dia em que alguém pergunta por que os números de receita da apresentação para o conselho não batem com o banco de dados, e de repente todo mundo quer uma solução de verdade.

Por que a exportação manual de CSV não escala

O fluxo de exportar e colar não é apenas trabalhoso - é ativamente arriscado. Você está fazendo uma cópia manual dos dados em um momento específico no tempo e colocando esse recorte estático em um lugar onde as pessoas o tratam como informação atual.

Segundo uma pesquisa de 2023 da Fivetran, 67% dos analistas de dados gastam mais de 4 horas por semana em tarefas manuais de movimentação de dados que poderiam ser automatizadas. Isso vale para todas as ferramentas, mas a sincronização entre planilhas e bancos de dados aparece consistentemente no topo da lista.

Para uma equipe financeira que roda ciclos de reporting semanais, um export desatualizado do Postgres significa que os números do DRE estão dias ou semanas atrás dos dados reais de transação. O problema não é incompetência técnica - é que o caminho fácil (baixar CSV, colar no Sheets) não funciona além do "uma vez só".

As 4 abordagens, comparadas

A escolha certa depende de três fatores: você tem acesso a um desenvolvedor, está disposto a pagar por infraestrutura, ou precisa de algo que funcione sem escrever uma linha de código?

Apps Script + JDBC: o caminho gratuito, mas que exige suporte técnico

Para quem é: equipes com um desenvolvedor ou profissional de TI disponível para configurar regras de firewall, gerenciar credenciais e manter o script em funcionamento.

Para quem não é: analistas financeiros que precisam de uma solução autônoma, sem depender de chamado técnico.

O Google Apps Script suporta conexões JDBC diretamente com o PostgreSQL. Você escreve uma função que abre a conexão, executa uma query e grava os resultados em um intervalo nomeado. Gatilhos automatizados cuidam da atualização periódica.

function syncFromPostgres() {
  const conn = Jdbc.getConnection(
    'jdbc:postgresql://seu-host:5432/seu_banco',
    'usuario',
    'senha'
  );
  const stmt = conn.prepareStatement(
    'SELECT data, receita, cmv, margem_bruta FROM financeiro.dre WHERE data >= CURRENT_DATE - 90'
  );
  const results = stmt.executeQuery();
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('DRE');
  let row = 2;
  while (results.next()) {
    sheet.getRange(row, 1, 1, 4).setValues([[
      results.getString(1),
      results.getFloat(2),
      results.getFloat(3),
      results.getFloat(4)
    ]]);
    row++;
  }
  results.close();
  conn.close();
}

Funciona, mas tem limitações reais. O suporte a JDBC do Google exige que sua instância PostgreSQL seja acessível publicamente ou que esteja na lista de permissões para os intervalos de IP do Google - uma concessão de segurança que muitas equipes de TI não vão aceitar. Em março de 2026, o Google não publica uma lista estável de endereços IP do Apps Script para liberação no firewall, o que transforma a configuração em um jogo de adivinhação.

O tempo máximo de execução do Apps Script é de 6 minutos para contas pessoais e 30 minutos para o Google Workspace. Se sua query retornar mais do que alguns milhares de linhas, você vai bater nesse limite.

Conectores ETL: certo para alguns times, exagero para outros

Ferramentas como Fivetran, Airbyte e Stitch sincronizam suas tabelas do Postgres com o Google Sheets - ou, mais comumente, com o BigQuery, que você então conecta ao Sheets. A configuração é genuinamente simples: configure a fonte, autentique o destino, agende a sincronização.

O que raramente aparece na conversa de vendas: para implementar isso na maioria das empresas de médio porte, você vai precisar abrir chamado para o TI, passar por aprovação de segurança e provavelmente esperar semanas. Não é algo que um analista coloca no ar em uma tarde.

A contrapartida também é custo. O plano base do Fivetran começa por volta de R$ 500/mês e é precificado por linhas ativas mensais. O nível cloud do Airbyte parte de cerca de US$ 3 por milhão de registros sincronizados. Para um time que precisa sincronizar 3 tabelas em uma agenda diária, provavelmente vale a pena. Para um analista que quer rodar queries ad-hoc contra uma instância Postgres de produção, é exagero.

O problema maior: conectores ETL replicam tabelas inteiras. Você não escreve SQL contra a fonte - configura quais tabelas sincronizar e depois consulta o destino. Se quiser executar um JOIN customizado entre 4 tabelas com condições de filtro específicas, essa lógica precisa existir em algum ponto posterior do pipeline.

Como o DuckDB conecta o PostgreSQL ao Google Sheets sem ETL

O DuckDB inclui uma extensão nativa que conecta um banco PostgreSQL como fonte consultável em tempo real. Em vez de replicar tabelas para um data warehouse intermediário, você consulta o Postgres diretamente e os resultados chegam no intervalo da planilha que você definir.

Internamente, a conexão usa esta estrutura:

ATTACH 'dbname=analytics user=readonly password=... host=db.interno port=5432'
  AS pg (TYPE postgres);

SELECT
  date_trunc('month', t.criado_em) AS mes,
  p.nome                           AS produto,
  SUM(t.valor)                     AS receita,
  COUNT(*)                         AS qtd_transacoes
FROM pg.transacoes t
JOIN pg.produtos p ON t.produto_id = p.id
WHERE t.criado_em >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

O que diferencia essa abordagem do ETL: o SQL roda do zero a cada execução, contra dados ao vivo. Você não está consultando uma cópia de ontem - está consultando o banco agora.

Para quem não quer escrever SQL, ferramentas que usam DuckDB como motor permitem descrever o que você precisa em linguagem natural - por exemplo, "Traga os últimos 90 dias de pedidos agrupados por categoria de produto" - e o SQL é gerado e executado automaticamente.

Como conectar o PostgreSQL ao Google Sheets com o ModelMonkey

1. Abra o painel lateral no Google Sheets
2. Acesse Fontes de Dados e selecione Adicionar Conexão
3. Escolha PostgreSQL como tipo de provedor
4. Informe host, porta, nome do banco e schema
5. Forneça as credenciais - elas são criptografadas via Google Cloud KMS e nunca armazenadas em texto puro
6. Clique em Testar Conexão para verificar o acesso
7. Com a conexão ativa, execute em linguagem natural: "Traga os últimos 90 dias de pedidos agrupados por categoria de produto" - a ferramenta converte para SQL, executa contra sua instância Postgres via DuckDB e grava os resultados no intervalo que você especificou

Como os dados do Postgres se encaixam no seu modelo existente

Essa é a pergunta que nenhum artigo técnico costuma responder: "Se os dados chegarem numa aba nova, o que acontece com minhas fórmulas?"

A resposta prática é: depende de onde você manda os dados chegar - e com uma estrutura simples, tudo funciona sem quebrar nada.

Crie uma aba dedicada para inputs. Separe uma aba - chame de Dados_Base, Raw_Data ou o nome que fizer sentido para o seu modelo - que funcione exclusivamente como receptora dos dados do Postgres. Nenhuma fórmula complexa vive ali; apenas dados brutos em colunas organizadas. Suas outras abas (DRE, Balanço, FCFF, ou o que for) referenciam essa aba via VLOOKUP, INDEX/MATCH ou referências diretas de célula.

O recálculo em cascata é automático. Quando você executa a consulta e novos dados chegam na Dados_Base, o Google Sheets recalcula automaticamente todas as fórmulas que dependem daquele intervalo - em cascata, aba por aba. Se o DRE referencia a Dados_Base, ele atualiza. Se o Balanço referencia o DRE, ele atualiza. Se o modelo de FCFF depende do Balanço, ele também atualiza. Você não precisa fazer nada além de executar a consulta.

Defina o intervalo de destino com precisão. Ao configurar a consulta, especifique exatamente qual célula inicia a colagem dos resultados - por exemplo, Dados_Base!A2. Isso evita que uma atualização sobrescreva um intervalo maior do que o esperado ou apague os cabeçalhos que você mantém na linha 1.

O argumento que funciona com seu gestor. Com essa estrutura, quando alguém perguntar de onde vêm os números, a resposta é direta: "Essa aba puxa direto do banco de dados, atualizado hoje de manhã." Sem copiar CSV, sem exportar manualmente, sem risco de estar olhando para dados de terça-feira numa reunião de sexta.

O que ninguém te conta sobre credenciais do banco de dados

Todas as abordagens, exceto o CSV, exigem que suas credenciais do Postgres fiquem armazenadas em algum lugar.

O Apps Script armazena credenciais nas propriedades do script, visíveis para qualquer pessoa com acesso de editor ao projeto - e isso costuma ser mais gente do que você esperaria. A documentação do Google Apps Script deixa claro que "as propriedades do script são compartilhadas entre todos os usuários de um script", o que significa que qualquer colaborador da sua planilha pode ler a senha do banco de dados se você a armazenar ali.

Ferramentas ETL gerenciam isso melhor: cofres criptografados com controle de acesso granular são padrão do setor. O DuckDB por si só não resolve o problema de armazenamento de credenciais - depende de como a ferramenta que você usa por cima o implementa. Antes de adotar qualquer solução, pergunte explicitamente: onde as credenciais ficam armazenadas e quem tem acesso a elas?

Essa distinção importa especialmente se sua instância Postgres contém dados financeiros de produção, informações de clientes ou qualquer dado sujeito a compliance.

Perguntas frequentes

Preciso saber SQL para conectar o PostgreSQL ao Google Sheets?

Depende da abordagem. Apps Script e DuckDB puro requerem SQL - você escreve a query diretamente. Ferramentas ETL como Fivetran não exigem SQL para a sincronização em si, mas você precisará dele para consultar os dados no destino. Ferramentas que aceitam linguagem natural (as que usam DuckDB como motor) permitem descrever o que você precisa sem escrever uma linha de código.

O Google Sheets consegue conectar diretamente a um banco PostgreSQL?

Não de forma nativa. O Google Sheets não tem um conector embutido para PostgreSQL. Você precisa de uma camada intermediária: Apps Script via JDBC, uma ferramenta ETL ou uma solução baseada em DuckDB. Das três, o DuckDB é a que mais se aproxima de uma "conexão direta" - sem replicar dados para um destino intermediário antes de chegar na planilha.

Com que frequência os dados podem ser atualizados?

Depende do método. Apps Script pode ser agendado para rodar de hora em hora (ou com mais frequência, com configuração cuidadosa). Ferramentas ETL oferecem agendamentos de 15 minutos a diário, conforme o plano. DuckDB consulta ao vivo sempre que você executa a query - sem cache: os dados refletem o estado atual do banco naquele momento.

A atualização vai quebrar as fórmulas das outras abas?

Não, se você separar claramente a aba de inputs (onde os dados do Postgres chegam) das abas de cálculo (onde suas fórmulas vivem). Com essa separação, uma atualização apenas sobrescreve o intervalo de dados brutos, e o Google Sheets recalcula as fórmulas dependentes automaticamente em cascata - sem que você precise fazer mais nada.

É seguro armazenar credenciais do banco de dados no Google Sheets?

No Apps Script, as credenciais ficam nas propriedades do script - acessíveis a qualquer editor da planilha. Para dados financeiros ou de produção, esse modelo não é adequado. Soluções que adotam criptografia de chave por usuário (como via Google Cloud KMS) oferecem um modelo de segurança significativamente mais robusto para ambientes corporativos.