Can Intellrise connect to my database?

The one-sentence answer

Intellrise queries your database from our application servers, not from inside your browser. So your database has to accept an inbound connection from the internet. If it does, setup is just a form: host, port, database name, user, password — then Connect, which saves the details and dials your database in the same step, and reports back either how many tables it found or the exact error your database returned.

If your database only listens on localhost, sits inside a private VPC, or is behind an IP allowlist you cannot add to, we cannot reach it directly. That is a straight no, not a maybe — jump to “If we cannot reach your database” below, where two options need no network access whatsoever.

What your database needs

1. A hostname or IP address that resolves from the public internet. localhost, 127.0.0.1 and private ranges (10.x.x.x, 192.168.x.x, 172.16–172.31.x.x) all point at your own network rather than ours, so they cannot work.
2. The database port reachable over TCP. Leave the port field blank and we use the standard default: 5432 for PostgreSQL, 3306 for MySQL, 5439 for Redshift.
3. A user with read access to the schema you want to ask about. A read-only user is the right choice. On our side PostgreSQL, MySQL and Redshift sources are attached with the driver's own read-only flag set, so a write is refused by the database driver rather than by our word list. “Create the read-only user” below has the exact statements for PostgreSQL, MySQL and Redshift, and says which of them we have run ourselves.
4. For PostgreSQL specifically, a server that accepts SSL. We always connect with sslmode=require and there is no setting to turn it off, so a Postgres server configured to refuse encrypted connections will fail to connect.
5. MySQL and Redshift are connected without an explicit SSL parameter today, so those follow whatever your server negotiates on its own. If an encrypted link is a hard requirement on either of those two, email contact@intellrise.com before you connect rather than assuming it either way.

Create the read-only user (copy-paste SQL)

Every page here that talks about connecting a database tells you to use a read-only user, and until recently none of them showed you how. Here are the statements — and first, what happens if you skip them. Since 5 September 2026 the connect flow asks your database what the account you gave us is allowed to do, and puts the answer on screen: that it can write to your tables, that it cannot, or that we could not tell. Give Intellrise an owner account and it is still accepted — the check reports, it does not refuse — but you will not find that out a month later. On PostgreSQL it follows role membership too, so an account that can only write after a SET ROLE is reported as able to write. What it cannot see: a trigger, or a function running as its definer.

What we do on our side is refuse to write. PostgreSQL, MySQL and Redshift sources are attached in read-only mode. And every statement, whether you typed it or the model wrote it, is checked before it runs and refused if it contains any of eighteen keywords — DROP, DELETE, UPDATE, INSERT, CREATE, ALTER, ATTACH, DETACH, TRUNCATE, COPY, EXPORT, GRANT, REVOKE, MERGE, CALL, PRAGMA, INSTALL and LOAD, the whole list rather than a sample, counted in the code on 31 August 2026. Calling that a keyword blocklist rather than a permission model is deliberate, and if you write SQL you already know why: it is a string check, and string checks are the category of thing people get around. It is a promise about our behaviour, and it is only worth what our code is worth. The GRANT below is the same promise in a form that does not require you to trust ours — which is why it is the one we would rather you used.

Run these as an administrator of the database. Replace the placeholder password with a real one, and the database and schema names with yours.

-- Run as a superuser or the database owner.
CREATE ROLE intellrise_ro LOGIN PASSWORD 'put-a-long-random-password-here';
GRANT CONNECT ON DATABASE your_database TO intellrise_ro;
GRANT USAGE ON SCHEMA public TO intellrise_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO intellrise_ro;

-- So tables you create later are readable without re-running the GRANT:
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO intellrise_ro;

-- Run as an administrator.
CREATE USER 'intellrise_ro'@'%'
  IDENTIFIED BY 'put-a-long-random-password-here';
GRANT SELECT ON your_database.* TO 'intellrise_ro'@'%';

-- No FLUSH PRIVILEGES needed. MySQL reloads the grant tables itself
-- after account-management statements like these.

-- Run as a superuser. Redshift requires 8-64 characters with at least one
-- uppercase, one lowercase and one number, and rejects ' " \ / and @.
CREATE USER intellrise_ro PASSWORD 'PutALongRandomPassword1';
GRANT USAGE ON SCHEMA public TO intellrise_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO intellrise_ro;

-- Redshift gives every new user CREATE on the public schema. Take it back:
REVOKE CREATE ON SCHEMA public FROM intellrise_ro;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO intellrise_ro;

Which of these we actually ran: the PostgreSQL one. It was executed end to end on PostgreSQL 18.3 on 16 August 2026, in a throwaway database, and this is what came back. SELECT returned rows. INSERT, UPDATE and DELETE each returned “permission denied for table orders”. DROP returned “must be owner of table orders”. CREATE TABLE returned “permission denied for schema public”. The schema query Intellrise itself runs still listed the table — that query only ever lists relations the connecting role is allowed to SELECT from, so the analyst can see the table it is not allowed to change.

The MySQL and Redshift blocks we did not run. They are written from each vendor's own documentation, read on 16 August 2026: dev.mysql.com/doc/refman/8.0/en/create-user.html and .../grant.html, and docs.aws.amazon.com/redshift/latest/dg/r_CREATE_USER.html. If one of them fails on your version, send the error to contact@intellrise.com and we will fix this page — you are reading it because someone else already had to guess.

One thing that will bite you weeks later. ALTER DEFAULT PRIVILEGES only covers tables created by the role that ran it. In our test a table created afterwards by that same role was readable with no extra grant — but a table created by a different owner was not, and it did not appear in the schema listing at all, so it was invisible to Intellrise rather than visibly broken. If a table you can see in your own client is missing here, that is the first thing to check. Re-running GRANT SELECT ON ALL TABLES IN SCHEMA fixes it; running ALTER DEFAULT PRIVILEGES once for each role that creates tables prevents it. On Redshift the same statement takes a FOR USER clause for exactly this reason. This matters most if someone else — a contractor, an ETL job — creates tables in your database, which is the common case rather than the exotic one.

To check it worked on PostgreSQL, connect as the new role and run: SELECT table_name, privilege_type FROM information_schema.table_privileges WHERE grantee = current_user ORDER BY table_name, privilege_type; — every row should read SELECT. We ran the same query as a role that also held INSERT and UPDATE and both showed up, so the query does tell the two cases apart rather than always printing SELECT. On MySQL the equivalent is SHOW GRANTS FOR 'intellrise_ro'@'%'.

None of this asks you to take our word for the test above. The five PostgreSQL statements plus that privilege query reproduce the whole thing in a scratch database in about two minutes, which is how we would check a vendor's claim too.

A note on that @'%' in the MySQL statement: it means “from any host”, and you will reasonably want to narrow it. Here you hit a real dead end rather than advice we are withholding. We connect from shared ranges rather than from one address, so there is no single host to name. (If you are filling in a data-processing schedule, every provider that processes data on our behalf is named, with what each one receives, in section 5 of intellrise.com/privacy.) And MySQL's own manual now says wildcards in the host part are “deprecated as of MySQL 8.0.35, and thus subject to removal in a future version of MySQL” (read 16 August 2026). So on 8.0.35 or newer, @'%' works today and is on its way out, and we cannot hand you an exact host to replace it with. Restricting by firewall to the two ranges above is the control that actually holds. And if that rule is not yours to make — it belongs to a hosting provider, or to a ticket someone else works through — the two routes under “If we cannot reach your database” below need no inbound access at all.

If your database is behind an IP allowlist

Allowlist our outbound ranges. As of 15 August 2026 our servers connect from 74.220.52.0/24 and 74.220.60.0/24 — read off our hosting provider's dashboard that day, and confirmed the same day by asking our own running backend what address it goes out from (74.220.52.217, inside the first range). These are our provider's regional ranges and are shared with its other customers, so allowlisting them is narrower than opening the port to the internet but is not a rule that admits only us. Email contact@intellrise.com before you rely on them and we will re-check the current values for you.

If you have to justify that to someone else, here is the sentence we would use, and you are welcome to check it rather than take it: allowlisting the ranges means only machines inside our host's regional network can even attempt a connection — and attempting is all it buys them, because they would still need the password and whatever the read-only grant allows. It narrows the door. It does not make the door yours alone. Anyone telling you a shared cloud range does is selling something. And if you have just read a pair of shared ranges and concluded this is now out of your hands, it does not have to be: you do not need a firewall rule at all to use Intellrise. A Google Sheet connects without one on the free plan, and so does a CSV or Excel export of the same data on the 14-day Pro trial.

Until 15 August 2026 this page refused to print those addresses, on the grounds that a published IP list goes stale the day the infrastructure changes, nobody notices, and you are the one left debugging a timeout. That reasoning still holds, which is why the date is stamped above and why we would rather you emailed us before relying on it. What changed is that ranges turned out to be far more durable than the per-instance address, and that three separate people had already stopped at this exact question — at which point withholding the answer was costing more than a stale line would.

If we cannot reach your database

Two options need no inbound network access at all:

1. Connect a Google Sheet. Intellrise reads it through Google's API once you authorize it, so nothing has to be open on your network. This works on the Free plan.
2. Upload a CSV or Excel extract. Also no network access needed — with one limit worth stating plainly: file upload is a Pro feature and is not on the Free plan, though every new account starts with 14 days of Pro.

What Intellrise does not support

There are no SSH tunnels, no VPC peering and no on-premise agent today. Not in beta, not behind a flag, not on a plan — they do not exist, and this sentence is here so you find that out before you sign up rather than after.

If one of those is what your setup requires, we would rather hear it than lose you quietly. Email contact@intellrise.com with three things: which one you need (tunnel, VPC peering, or an agent that runs inside your network), one line about where the database sits, and whether the blocker is the network itself or a data-processing agreement your client requires. That is a request for information, not a waiting list — we are not promising any of the three, and we will not tell you it is coming. What it buys you is a direct answer about whether we are ever likely to fit, and what it buys us is the only reliable way to find out how many people this actually stops.

Which case you are in, and how to check

Whether any of the limits above apply comes down to one thing: whether your database already accepts a connection from outside its own network. A managed PostgreSQL that hands you a public hostname — Neon and Supabase do that by default — already accepts exactly the kind of connection Intellrise makes. Amazon RDS and Cloud SQL can too, but only if the instance was created as publicly accessible, which is not their default; if yours sits in a private subnet, you are in the “straight no” case above rather than this one.

Your credentials are encrypted at rest with AES-256-GCM and are only ever shown back to you masked, and Intellrise attaches PostgreSQL, MySQL and Redshift sources read-only at the driver. If you want the detail before you type a password into anything, read intellrise.com/security first — that is the right instinct.

You do not have to take our word for any of this. Every new account starts on a 14-day Pro trial with no card, and Settings → Data Sources has a Test connection button that either reports how many tables it found or shows you the exact error your database returned — usually enough to tell a firewall problem from a password problem.

If you would rather look before creating an account at all, the demo at intellrise.com/demo runs on a sample dataset with no signup.