Connect databases

Spreadsheets are the fastest way in, but most real data lives in databases. Tablize connects to yours directly — no replication, no ETL pipeline, no intermediate warehouse.

What you’re doing, behind the scenes, is handing Tablize a read-only credential. The Agent issues SQL against your database, live, whenever you ask a question. Your data doesn’t leave its home.

Supported engines

Engine	Notes
PostgreSQL	Any version from 12 onward. Works with TimescaleDB, PostGIS, pgvector extensions already installed.
MySQL / MariaDB	MySQL 5.7+ or MariaDB 10.4+. Full-text indexes honored.
Supabase	Managed Postgres — you get the pooled connection string from your Supabase dashboard. Works the same as self-hosted PG.
SQLite	Upload the .sqlite or .db file (see Upload files). Tablize hosts a copy.
Snowflake, BigQuery, Redshift	Via Integrations rather than a raw connection string — warehouse quirks are worth their own page.

Recommended: create a read-only role

Tablize never needs write access. For production databases, create a dedicated role:

-- Postgres
CREATE ROLE tablize_reader WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE your_db TO tablize_reader;
GRANT USAGE ON SCHEMA public TO tablize_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO tablize_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO tablize_reader;

Use this role’s credentials in the connection string. The Agent can’t DROP or UPDATE even if asked to — the database enforces it, not Tablize.

If you want the Agent to write (for generated Apps that need CRUD), grant INSERT / UPDATE / DELETE on specific tables only. Never give broad write access to a shared connection.

Connecting

Workspace → Integrations → Database → paste your connection string. Formats Tablize accepts:

postgresql://user:pass@host:5432/dbname
postgres://user:pass@host:5432/dbname?sslmode=require
mysql://user:pass@host:3306/dbname

Click Test connection. Tablize runs SELECT 1, reports back the server version and visible schemas. If that passes, click Save.

On save, Tablize introspects:

• Every schema the role can see.
• Every table, view, and materialized view.
• Every column’s type, default, and nullability.
• Primary keys and foreign keys — these inform auto-joins.

The Agent now has a map of your database. You can ask your first question.

Network requirements

Tablize Cloud reaches your database from our servers, not from your browser. Three options for making it reachable:

• Public endpoint with TLS. Simplest. Most managed DBs (Supabase, Neon, RDS) ship this by default. Use sslmode=require in the URL.
• Allow-listed IPs. We publish a static list of egress IPs — add them to your firewall or security group. See the console IP allowlist page after you sign up.
• Reverse tunnel (Max plan). For databases with no public endpoint, we provide a small agent you run inside your network that opens an outbound connection to Tablize. No inbound rules needed.

For self-hosted Tablize, the database just needs to be reachable from your Tablize host. Use a private network, bind-mount, whatever you have.

Large databases

Tablize doesn’t copy your data, but it does cache query results for speed. For databases over ~100 GB:

• Give the Agent sample hints. When you first connect, tell it which tables are hot (frequently queried) and which are cold. It’ll narrow its query patterns.
• Use partitioned tables. If you already partition by date, the Agent honors partitions — no full-table scans for “last week.”
• Consider a read replica. Point Tablize at a replica if your primary is load-sensitive. Replication lag < 1 min is fine for almost all uses.

Multiple databases

You can connect as many as you want — one Postgres prod, one MySQL legacy, one Supabase for a side project. The Agent picks the right one based on which table you mention or which database you mention by name.

Cross-database joins use Postgres’ Foreign Data Wrapper — fast enough for ad-hoc joins, not a replacement for a proper warehouse for heavy joining workloads. If you find yourself doing cross-database joins every day, consider a lightweight warehouse and connect that.

What the Agent can and can’t do

Can:

• Read any table / view the role can SELECT.
• Explain schema, write exploratory SQL, generate EXPLAIN plans.
• Build Dashboards and Apps on top of the data (read-only apps).
• Run Scripts and Watches that query the database on a schedule.

Can’t:

• Write back to read-only tables. That’s enforced by your database role, not by Tablize.
• Run migrations or ALTER TABLE. Even with write grants, schema changes are out of scope by design — use your migration tool.
• Keep data if the connection goes away. Uncached queries need the database available; cached ones stay until invalidated.

Common gotchas

• SSL failures. The most common error is SSL connection required — add ?sslmode=require. Or, rarely, sslmode=no-verify if your cert is self-signed.
• Connection pool exhaustion. If your DB has a small max_connections, Tablize’s pooling can compete with your app. Use a pgbouncer or route Tablize to a replica.
• Permission denied on a specific table. The role introspects system catalogs, which includes tables it can’t SELECT. Either grant SELECT, or filter the table out via --exclude in the connection options.
• Timezone mismatches. If the Agent reports “Tuesday” and you think “Monday,” check timezone on the role. Set it explicitly.

Next steps

• Webhooks & APIs — for data your app produces but isn’t in a database yet.
• Integrations — for SaaS data where you’d rather not build the sync yourself.
• Asking questions — now that your database is connected, ask it something.