Connecting your warehouse

Celiq connects directly to your data warehouse. All queries run against your live data — Celiq never copies or caches your raw tables. You stay in control of your data.

Supported warehouses

To connect a warehouse, navigate to Admin → Connections → New connection and select your warehouse type.

PostgreSQL

• Host (e.g. db.example.com)
• Port (default: 5432)
• Database name
• Username and password

CREATE USER celiq_reader WITH PASSWORD 'your_password';
GRANT CONNECT ON DATABASE your_database TO celiq_reader;
GRANT USAGE ON SCHEMA public TO celiq_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO celiq_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO celiq_reader;

BigQuery

Two projects, one connection

BigQuery has two different project IDs that serve different purposes. Mixing them up is the most common misconfiguration:

The Data Project ID field in Celiq is always the project that owns the dataset. Your service account's project_id in the JSON key file is your billing project — these are often different.

Your full table path will be: {Data Project ID}.{dataset}.{table_name}

For example: bigquery-public-data.thelook_ecommerce.orders

The connection form shows a live preview of this path as you type, so you can verify it looks correct before saving.

Required IAM roles

Grant the Celiq service account both of these roles on the relevant project:

• BigQuery Data Viewer — read table data and schema
• BigQuery Job User — run query jobs

If your data lives in a different project than your billing project (common when querying bigquery-public-data or a shared dataset), also grant BigQuery Data Viewer on the data project.

Dataset location

Celiq automatically detects your dataset's region. You do not need to specify a location — just the project ID and dataset name. Celiq reads the location from the dataset metadata and routes queries to the correct region.

If your dataset is in a non-default region (e.g. EU, us-central1), Celiq handles this transparently.

Service account setup

1. Open GCP IAM and create a new service account.
2. Grant the two IAM roles above.
3. Under Keys, click Add key → Create new key → JSON.
4. Download the JSON key file.
5. In Celiq, open Admin → Connections → New connection → BigQuery.
6. Paste the entire contents of the JSON key file into the Service account JSON field.
7. Enter your Billing project ID (the project that query costs are charged to).
8. Enter your Default dataset — the BigQuery dataset Celiq will query by default (e.g. thelook_ecommerce).

Cross-project datasets

If your data lives in a different project than where you are billed:

• Billing project — the project ID where query costs are charged. Usually the same project as your service account.
• Dataset project — the project where your data actually lives (enter this in the Data project ID field).

Celiq will use the billing project for query execution but reference tables in the data project using fully qualified names (data_project.dataset.table).

Snowflake

• Account identifier (e.g. xy12345.us-east-1)
• Warehouse (compute cluster)
• Database
• Schema
• Username and password (or key-pair authentication)

Amazon Redshift

• Host (cluster endpoint)
• Port (default: 5439)
• Database name
• Username and password

Firewall and IP allowlisting

If your warehouse requires IP allowlisting, contact support@celiq.co for the current list of Celiq egress IP addresses. These are static and do not change without notice.

Testing your connection

After filling in the connection form, click Test connection. Celiq will:

1. Attempt to open a connection to your warehouse
2. Run SELECT 1 to verify read access
3. Read the schema of the default database/dataset

A green tick means the connection is working. If the test fails, the error message will tell you exactly what went wrong — authentication failure, network timeout, missing permissions, etc.

Synced connectors

Some data sources sync to your warehouse daily rather than being queried directly. Configure the sync in Admin → Connectors.

Once synced, data appears as a regular table in your warehouse and can be modelled with Forge like any other source.

Table reference formats

How you write physical_table in a node depends on your warehouse. Using the wrong format is the most common cause of "table not found" errors.

Row-level security

Celiq enforces row-level security through Data Keys — defined in your node CML and enforced on every query.

node: orders
table: orders
data_key:
  field: workspace_id
  value: "{{ current_workspace_id }}"

Field-level security (Data Gates)

Data Gates hide fields from specific roles.

fields:
  - name: salary
    type: decimal
    data_gate: finance_only

Connection credentials are encrypted at rest

Celiq encrypts all warehouse credentials using AES-256 before storing them. The encryption key is environment-specific and never logged. Credentials are decrypted only at query time, in memory, and are never written to disk or included in logs.

Data quality checks per warehouse

Before Orion returns a number — and before a mosaic tile renders a KPI — Celiq runs a data quality check: is the underlying data fresh, and is it complete? How that freshness check is performed depends on your warehouse, because each engine exposes table metadata differently.

How freshness is determined

Celiq establishes "how recent is this data?" using, in order of preference:

1. The result's own date column — the most recent value of the date dimension in the query result. This works on every warehouse and is the primary signal.
2. Table metadata — the warehouse's recorded last-modified time for the source table, used as a corroborating signal where available.

The completeness check (row-count anomaly detection) compares the current run against the previous run and is identical across all warehouses.

Behaviour by warehouse

In all cases, when table metadata is unavailable or unreliable, Celiq falls back to the most recent date in the query result — so freshness checking works everywhere, just with less corroboration on some engines.

BigQuery freshness check limitations

BigQuery exposes a table's last_modified_time, but it has limitations Celiq has to work around:

• It is coarse. last_modified_time updates when the table is written, not necessarily when the data period you are querying completes. A daily-partitioned table can show a recent modified time while the partition for "today" is still filling.
• Streaming inserts lag. Tables fed by the streaming buffer can report a modified time that trails the actual most recent rows by a few minutes.
• Views and wildcard tables. Freshness metadata is not meaningful for views or *-wildcard table queries; Celiq uses the result's date column instead.

Because of this, on BigQuery, Celiq treats the most recent date in the query result as the authoritative freshness signal and uses last_modified_time only as a secondary check. If a BigQuery tile shows an unexpected ⚠️ stale indicator, confirm that the date dimension in the reveal points at the column that actually advances with each load (e.g. the partition column), not a static created-at field.