Conectar um data warehouse Postgres

Este guia mostra como conectar um banco PostgreSQL ao Saiku Cloud, de ponta a ponta. Cinco minutos se o seu data warehouse já é público; dez se precisar configurar uma role somente leitura.

Impacto no tier: todos os tiers do Saiku Cloud (Starter, Team, Business) suportam BYOC do Postgres.

O que você vai precisar

Uma instância PostgreSQL 12+ que seja alcançável por um endereço IPv4 público. Clientes do Saiku Cloud hospedado nos tiers Starter/Team/Business precisam disso — clientes Enterprise rodando em VPC peering privado (veja PrivateLink para Postgres do cliente) ganham acessibilidade por rede privada.
Acesso admin ao seu data warehouse para criar uma role somente leitura (ou as credenciais de uma role somente leitura existente).
Cinco minutos.

Passo 1 — Allowlist do nosso IP de egress

Todas as consultas do Saiku Cloud para o seu data warehouse saem de um único IP estático:

87.99.153.244

Adicione isso ao firewall / security group / allowlist de rede do seu data warehouse antes de testar a conexão. O wizard de conexão mostrará o mesmo IP na hora do teste, então você pode copiar de novo de lá — mas fazer isso antes evita o erro HOST_UNREACHABLE que você veria no primeiro teste.

Lugares comuns de allowlist:

AWS RDS: regra de entrada do security group da VPC → porta 5432 → origem 87.99.153.244/32.
Google Cloud SQL: Connectivity → Authorized networks → adicione 87.99.153.244/32.
Azure Postgres: Networking → Firewall rules → adicione uma regra permitindo 87.99.153.244 para 87.99.153.244.
Self-hosted: entrada de host em pg_hba.conf, mais qualquer firewall que esteja na frente (UFW, iptables, edge do provedor de nuvem).

O IP é estável — sobrevive a reboots e reconstruções de imagem. Nos comprometemos a dar ao menos 30 dias de aviso antes de qualquer rotação. Política completa: veja nosso compromisso de estabilidade do IP de egress.

Passo 2 — Crie uma role somente leitura no Postgres

O Saiku Cloud só lê do seu data warehouse — nunca escreve, nunca altera schemas, nunca cria objetos. O formato de menor privilégio é uma role somente leitura dedicada:

-- As a Postgres superuser (or anyone with CREATEROLE):
CREATE ROLE saiku_read LOGIN PASSWORD 'pick-something-strong-here';

-- Grant access to the schemas + tables you want Saiku to see.
-- Adjust 'public' to whichever schema(s) your data lives in.
GRANT USAGE ON SCHEMA public TO saiku_read;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO saiku_read;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO saiku_read;

-- Future tables created in this schema should also be readable.
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO saiku_read;

Se seus dados estão espalhados por múltiplos schemas, repita os blocos GRANT USAGE + GRANT SELECT para cada um.

Passo 3 — Monte a URL JDBC

O formato:

jdbc:postgresql://<host>:<port>/<database>?sslmode=require

Exemplos concretos:

AWS RDS: jdbc:postgresql://mydb.abc123.us-east-1.rds.amazonaws.com:5432/sales?sslmode=require
Google Cloud SQL: jdbc:postgresql://1.2.3.4:5432/sales?sslmode=require (use o IP público do console do Cloud SQL)
Azure Postgres: jdbc:postgresql://mydb.postgres.database.azure.com:5432/sales?sslmode=require
Self-hosted: jdbc:postgresql://db.yourcompany.com:5432/sales?sslmode=require

Parâmetros chave:

sslmode=require é fortemente recomendado para qualquer data warehouse alcançável pela internet pública. A maioria dos serviços Postgres gerenciados já força SSL; require faz o cliente rejeitar fallback em plaintext.
sslmode=verify-full é mais estrito — também verifica que o hostname do cert do servidor bate. Use se a CA root do seu data warehouse está na nossa trust store (a maioria dos serviços gerenciados usa Let’s Encrypt ou uma CA conhecida, então isso funciona de cara).
Pule ?currentSchema=foo e ajustes similares do driver, a menos que tenha uma razão específica; o Saiku consulta com referências schema.table totalmente qualificadas em todo lugar.

Passo 4 — Conecte pelo wizard do Saiku Cloud

Faça login em https://cloud.saiku.bi/.
Vá em Conexões na barra lateral esquerda.
Em 1. Escolha o tipo de data warehouse, clique no tile Postgres.
Preencha:
- URL JDBC — a URL do passo 3.
- Usuário — saiku_read (ou o que tiver nomeado a role no passo 2).
- Senha — a senha do passo 2.
Clique em Testar conexão.

Se tudo estiver corretamente ligado, você verá um banner verde de resultado: ✓ Connection successful mais a versão detectada do Postgres. Siga para o passo 5.

Se você vir um banner vermelho de resultado, veja Solução de problemas abaixo para a matriz de triagem dos modos de falha.

Passo 5 — Salve a conexão

Após um teste bem-sucedido, o wizard renderiza uma seção 3. Salvar conexão. Preencha:

Senha (digite de novo para salvar) — a mesma senha que você testou. Não armazenamos a senha do formulário de teste para evitar trafegar uma credencial pelo estado da página.
Rótulo — um nome legível como Production warehouse ou Marketing analytics. Mostrado na lista de conexões + designer de cubo.

Clique em Salvar conexão. Vamos te redirecionar para o schema designer, onde você pode propor um cubo pelo fluxo de AI inference ou enviar um XML de schema Mondrian.

Solução de problemas

`✗ Connection failed (HOST_UNREACHABLE)` ou `(TIMEOUT)`

Não conseguimos alcançar o host na porta que você especificou. Causas mais comuns:

Firewall / allowlist — o passo 1 não foi feito ou não foi feito para o IP certo. Confirme que 87.99.153.244/32 está na allowlist do seu data warehouse + aplicado (alguns firewalls exigem restart / reaplicação).
DNS — o hostname na URL JDBC não resolve, ou resolve para um IP privado. Verifique do seu laptop: nslookup <host>. Nos recusamos a conectar a endereços RFC1918 / loopback / link-local por razões de proteção anti-SSRF — HOST_DENIED (não HOST_UNREACHABLE) é o resultado nesse caso.
Porta errada — o Postgres default é 5432, mas serviços gerenciados ocasionalmente usam uma porta custom (Heroku Postgres usa 5432, mas dentro de um túnel; algumas implantações on-prem usam 5433+).

`✗ Connection failed (AUTH_FAILED)`

Usuário ou senha errados. O wizard intencionalmente não distingue “usuário errado” de “senha errada” — isso é defesa contra ataques de credential-stuffing.

Confira o usuário — nomes de role do Postgres são sensíveis a maiúsculas (saiku_read ≠ Saiku_Read).
Tente conectar do seu laptop com psql "<URL JDBC sem o prefixo jdbc:>" para confirmar que as credenciais funcionam fora do Saiku.
Se você resetou a senha recentemente, garanta que aplicou a mudança no Postgres (ALTER ROLE saiku_read PASSWORD '...';) e reconectou qualquer pooler que possa estar cacheando o hash antigo.

`✗ Connection failed (DATABASE_NOT_FOUND)`

O host aceita suas credenciais, mas o nome do banco na URL JDBC não existe. Verifique o nome do banco — o Postgres geralmente tem tanto postgres quanto o banco da sua aplicação; você quer o segundo.

-- From psql, as any user with login:
\l         -- list databases

`✗ Connection failed (DIALECT_UNSUPPORTED)`

A URL não começa com jdbc:postgresql:. Se você colou uma URL jdbc:postgres: (sem -ql), o resolvedor de dialeto não bate — o driver JDBC do Postgres exige o token postgresql. Use os formatos de URL do passo 3 literalmente.

Qualquer outra coisa

Tire um screenshot do wizard com o banner vermelho de resultado visível (especificamente a linha Kind: ...) e mande para support@saiku.bi. O campo Kind nos diz em qual classe de falha estamos; a dica Try this embaixo dá nosso melhor palpite para a correção.

Enterprise: rede privada {#enterprise-private-network}

Para clientes Enterprise rodando uma configuração de rede privada, a regra do IP de egress acima é substituída por VPC peering ou PrivateLink para a sua instância Postgres. O fluxo do wizard de conexão é, fora isso, idêntico — cole a URL JDBC privada, teste, salve. Entre em contato com seu account team para provisionar o peering.

Teste com FoodMart

Quer testar o Saiku Cloud com esse dialeto antes de conectar seus próprios dados? Baixe o dataset de exemplo FoodMart empacotado para Postgres:

Dataset de exemplo FoodMart para Postgres