Connect a data source: what we ask for and why

Where to start

In the app, open Settings → Data Sources, then click Connect Data Source. Pick the type that matches your data and follow the prompts. You can add more than one source and switch between them.

Connection details and credentials are encrypted at rest (AES-256-GCM). We keep no standing copy of your source: PostgreSQL, MySQL and Redshift are attached read-only and queried in place; a Google Sheet is re-read from the Sheets API each session. What we keep is what an answer returned, not your source tables.

Connect a database

Supported databases are PostgreSQL, MySQL and Redshift.

One prerequisite before you start: Intellrise connects from our servers, not from your browser, so the database has to accept an inbound connection from the internet — and PostgreSQL connections always use sslmode=require. If your database is on localhost, inside a private VPC, or behind an IP allowlist, read “Database requirements” first; it lists what to check and what to do instead.

There is no SSL switch in the form to look for. PostgreSQL is always connected with sslmode=require and it cannot be turned off; MySQL and Redshift are sent without an explicit SSL parameter, so those follow whatever your own server negotiates.

If you would rather allowlist us than open the database to the internet: as of 15 August 2026 our servers connect from 74.220.52.0/24 and 74.220.60.0/24. Two things you should know before you paste those into a firewall rule. First, they are ranges rather than a single address — our hosting provider states an instance may use any address inside them, and on the day we checked ours answered from 74.220.52.217. Second, and more important for your risk assessment: these ranges are our provider's, shared with its other customers in the same region, not exclusive to Intellrise. Allowlisting them admits more than just us, which is a smaller hole than opening the port to everyone but is not a hole of size one. Email contact@intellrise.com before you rely on them and we will re-read the current values and confirm — infrastructure moves, and you would be the one debugging the timeout.

1. Click Connect Data Source and choose your database type.
2. Fill in the form. For PostgreSQL, MySQL and Redshift it asks for eight things: a display name, host, port, database name, schema (it pre-fills “public”), username, password, and a dbt target schema that is optional and can be left blank — plus a checkbox to make this your default source. There is no box to paste a whole connection string into, so if your provider only hands you a URL, read the values out of it yourself.
3. Click Connect. It stores your credentials encrypted and then immediately opens a connection to check them, so you find out on this screen instead of one question later: either “Connected — N tables found”, or a red banner carrying the exact error your database returned. A source that fails to connect is still saved, so nothing you typed is lost — correct the details with the pencil icon. Every saved source also keeps a Test button for re-checking it later. A read-only user is recommended, and the Database requirements article carries the CREATE ROLE and GRANT SELECT statements to make one. The same screen now also tells you what the account you actually gave us can do — a second line under the connection result, saying whether that account can write to your tables, cannot, or whether we could not tell. It never blocks the connection.

Connect a Google Sheet

1. Click Connect Data Source and choose Google Sheets.
2. Authorize Intellrise with your Google account when prompted.
3. Pick the workbook, then the tabs you want to query, and save. Each tab becomes a table.

Upload a CSV or Excel file

1. Click Connect Data Source and choose CSV or Excel.
2. Select your file. Make sure the first row holds the column headers.
3. Confirm the detected columns and save.

Then just ask

Once a source is connected, ask a question in plain English. Intellrise turns it into a query and returns the answer as a chart, table or short report you can save.

What gets sent to your AI provider

You bring your own AI key, so everything below goes to your provider account under your key — not to us, and never into our models. It is still your data leaving your machine, so here is the whole list rather than a reassuring sentence.

Every question sends three things: what you typed, the names and types of your tables and columns (plus any descriptions you or the semantic layer have saved), and the SQL. When a query finishes, the model also receives its column names, the row count and up to the first ten rows, so that the answer it writes is based on the numbers it describes; the rest of the result is not sent to the model.

One more path sends rows. AI Semantic Schema Learning, a Pro feature, is how the analyst works out that gmv excludes VAT rather than guessing from the column name: when you connect a source or refresh its schema, it sends up to three sample rows per table to your provider. That step does not run on the free tier at all.

If any of that is a problem for a particular table — a column of raw identifiers, say — the cleanest control is the one you already hold: connect with a role that cannot see it. What the role cannot select, we cannot send.

That control assumes the sensitive part is inside the rows. Often it is not. The names go out as written — the label you gave the source, each table (for a Google Sheet, the tab name, cleaned into a SQL-safe identifier), every column header, and any saved description. If a tab is called "Acme Corp 2026 orders", or a header is a client's name, then for you the names are the data, and no role grant hides them while still letting the model query that table. We cannot strip them either: the model needs the names to write the SQL. What works instead is renaming tabs and headers to neutral labels before you connect, or pointing that source at a key whose terms you have already cleared. Renaming has a ceiling, though, and it is better to hear it now: your question text is sent too, so a tab renamed to Client A protects nothing if the client's real name goes into the question.

What we cannot promise is what your provider does with it once it arrives: that is set by their terms, not ours, and the terms change with the tier. Google's Gemini API terms (effective 23 March 2026, read 28 August 2026) say that for Unpaid Services "Google uses the content you submit to the Services and any generated responses to provide, improve, and develop Google products and services and machine learning technologies", and the same page says "Do not submit sensitive, confidential, or personal information to the Unpaid Services." Between those two sentences Google's terms carry a third that a vendor review will ask about and that we had left out: "To help with quality and improve our products, human reviewers may read, annotate, and process your API input and output." Google says it takes steps first — "disconnecting this data from your Google Account, API key, and Cloud project before reviewers see or annotate it" — which unlinks who sent it, not what it says, so your table and column names are still in what a reviewer would read. A key on a Cloud project with an active billing account is a Paid Service, where the terms instead say Google "doesn't use your prompts ... or responses to improve our products". The paid branch has a cost of its own, and it belongs next to the recommendation rather than in a footnote: the same terms say "For Paid Services, Google logs prompts and responses for a limited period of time", for abuse detection and any legally required disclosure. And in the EEA, Switzerland or the UK the paid terms cover the free quota too. The same terms carry a second sentence about the EEA, in a different section, and it points the other way: under "Use Restrictions", Google says "You may use only Paid Services when making API Clients available to users in the European Economic Area, Switzerland, or the United Kingdom" (read 31 August 2026). Whether that binds a bring-your-own-key setup like this one — where the key and the Google Cloud project are yours, and our software calls Google with them — we do not have a settled answer, and we are not going to invent one. Both sentences sit in the same document at ai.google.dev/gemini-api/terms; if you are in one of those three places, read that one yourself and have whoever signs off on your vendors read it too.