Skip to content
Saiku Cloud

Connecting a Postgres warehouse

This guide walks you through connecting a PostgreSQL database to Saiku Cloud, end to end. Five minutes if your warehouse is already public; ten if you need to set up a read-only role.

Tier impact: every Saiku Cloud tier (Starter, Team, Business) supports Postgres BYOC.

What you’ll need

  • A PostgreSQL 12+ instance that’s reachable from a public IPv4 address. Cloud-hosted Saiku Cloud customers on Starter/Team/Business need this — Enterprise customers running on a private VPC peering setup (see PrivateLink to customer Postgres) get private-network reachability instead.
  • Admin access to your warehouse so you can create a read-only role (or an existing read-only role’s credentials).
  • Five minutes.

Step 1 — Allowlist our egress IP

Saiku Cloud’s queries to your warehouse all originate from a single static IP:

87.99.153.244

Add this to your warehouse’s firewall / security group / network allowlist before testing the connection. The connection wizard will surface the same IP at the moment of testing, so you can copy it again from there — but doing it ahead of time avoids the HOST_UNREACHABLE error you’d otherwise see on first test.

Common allowlist places:

  • AWS RDS: VPC security group inbound rule → port 5432 → source 87.99.153.244/32.
  • Google Cloud SQL: Connectivity → Authorized networks → add 87.99.153.244/32.
  • Azure Postgres: Networking → Firewall rules → add a rule allowing 87.99.153.244 to 87.99.153.244.
  • Self-hosted: pg_hba.conf host entry, plus whatever firewall sits in front (UFW, iptables, cloud provider’s edge).

The IP is stable — it survives reboots and image rebuilds. We commit to at least 30 days notice before any rotation. Full policy: see our egress-IP stability commitment.

Step 2 — Create a read-only role in Postgres

Saiku Cloud only ever reads from your warehouse — never writes, never alters schemas, never creates objects. The least-privilege shape is a dedicated read-only role:

-- 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;

If your data is spread across multiple schemas, repeat the GRANT USAGE + GRANT SELECT blocks for each one.

Step 3 — Build the JDBC URL

The shape:

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

Concrete examples:

  • 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 the Public IP from the Cloud SQL console)
  • Azure Postgres: jdbc:postgresql://mydb.postgres.database.azure.com:5432/sales?sslmode=require
  • Self-hosted: jdbc:postgresql://db.yourcompany.com:5432/sales?sslmode=require

Key parameters:

  • sslmode=require is strongly recommended for any warehouse reachable over the public internet. Most managed Postgres services enforce SSL anyway; require makes the client reject plaintext fallback.
  • sslmode=verify-full is stricter — it also verifies the server’s certificate hostname matches. Use it if your warehouse’s CA root is in our trust store (most managed services use Let’s Encrypt or a well-known CA so this works out of the box).
  • Skip ?currentSchema=foo and similar driver tweaks unless you have a specific reason; Saiku queries with fully-qualified schema.table references throughout.

Step 4 — Connect via the Saiku Cloud wizard

  1. Sign in at https://cloud.saiku.bi/.

  2. Navigate to Connections in the left sidebar.

  3. Under 1. Pick warehouse type, click the Postgres tile.

  4. Fill in:

    • JDBC URL — the URL from Step 3.
    • Username — saiku_read (or whatever you named the role in Step 2).
    • Password — the password from Step 2.

  5. Click Test connection.

If everything’s wired correctly, you’ll see a green outcome banner: ✓ Connection successful plus the detected Postgres version. Proceed to Step 5.

If you see a red outcome banner, see Troubleshooting below for the failure-mode triage matrix.

Step 5 — Save the connection

After a successful test, the wizard renders a 3. Save connection section. Fill in:

  • Password (re-enter for save) — the same password you tested with. We don’t store the test-form password to avoid round-tripping a credential through page state.
  • Label — a human-readable name like Production warehouse or Marketing analytics. Shown in the connections list + cube designer.

Click Save connection. We’ll redirect you to the schema designer, where you can either propose a cube via the AI inference flow or upload a Mondrian schema XML.

Troubleshooting

✗ Connection failed (HOST_UNREACHABLE) or (TIMEOUT)

We couldn’t reach the host on the port you specified. Most common causes:

  1. Firewall / allowlist — Step 1 wasn’t done or wasn’t done for the right IP. Confirm 87.99.153.244/32 is in your warehouse’s allowlist + applied (some firewalls require a restart / re-apply).
  2. DNS — the hostname in the JDBC URL doesn’t resolve, or resolves to a private IP. Verify from your laptop: nslookup <host>. We refuse to connect to RFC1918 / loopback / link-local addresses for SSRF-protection reasons — HOST_DENIED (not HOST_UNREACHABLE) is the surface in that case.
  3. Wrong port — Postgres defaults to 5432 but managed services occasionally use a custom port (Heroku Postgres uses 5432, but inside a tunnel; some on-prem deployments use 5433+).

✗ Connection failed (AUTH_FAILED)

Username or password is wrong. The wizard intentionally doesn’t distinguish “wrong user” from “wrong password” — that’s defence against credential-stuffing attacks.

  • Double-check the username — Postgres role names are case-sensitive (saiku_read ≠ Saiku_Read).
  • Try connecting from your laptop with psql "<JDBC URL minus the jdbc: prefix>" to confirm the credentials work outside Saiku.
  • If you reset the password recently, make sure you committed the change in Postgres (ALTER ROLE saiku_read PASSWORD '...';) and reconnected any pooler that might be caching the old hash.

✗ Connection failed (DATABASE_NOT_FOUND)

The host accepts your credentials but the database name in the JDBC URL doesn’t exist. Verify the database name — Postgres usually has both postgres and your application database; you want the latter.

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

✗ Connection failed (DIALECT_UNSUPPORTED)

The URL doesn’t start with jdbc:postgresql:. If you pasted a jdbc:postgres: (no -ql) URL, the dialect resolver doesn’t match — Postgres’ JDBC driver requires the postgresql token. Use the URL shapes from Step 3 verbatim.

Anything else

Take a screenshot of the wizard with the red outcome banner visible (Kind: ... line in particular) and send it to support@saiku.bi. The Kind field tells us which class of failure we’re in; the Try this hint underneath gives our best guess at the fix.

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

For Enterprise customers running a private network setup, the egress IP rule above is replaced by VPC peering or PrivateLink to your Postgres instance. The connection wizard’s flow is otherwise identical — paste the private JDBC URL, test, save. Contact your account team to provision the peering.

Try with FoodMart

Want to test Saiku Cloud with this dialect before connecting your own data? Download the FoodMart sample dataset packaged for Postgres:

FoodMart sample dataset for Postgres