Connectivity

Connecting your database

What MyDataTalk needs, what it can and cannot do once connected, and what to do when your database isn't reachable from the internet. Setting this up should take a DBA about ten minutes.

Give it a read-only role

Create a dedicated login rather than reusing an application user. Grant SELECT on the schemas you want answerable and nothing else. If a question can't be answered without a table you didn't grant, the answer is that it doesn't have access, which is the correct outcome.

Credentials are encrypted before they're stored

Connection parameters are AES-256-GCM encrypted at rest, envelope-encrypted through AWS KMS where that's configured, and never written to logs in plaintext. You can rotate or delete them at any time from the connection settings.

Only results travel, not tables

Queries run against your database and only the resulting rows come back. There's no bulk copy, no replication, and no background crawl of your data. The one exception is a spreadsheet you upload, which by definition has to be stored on our side.

The database has to be reachable

MyDataTalk runs as a hosted service, so it connects over the network like any other client: a hostname, a port, and TLS. For managed databases that already accept remote connections, that's all it takes.

The grants to run

Least privilege for each supported engine. Replace the names and use a generated password.

PostgreSQL

CREATE ROLE mydatatalk LOGIN PASSWORD 'a-strong-password';
GRANT CONNECT ON DATABASE your_db TO mydatatalk;
GRANT USAGE ON SCHEMA public TO mydatatalk;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mydatatalk;
-- Tables created later are covered too:
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO mydatatalk;

MySQL

CREATE USER 'mydatatalk'@'%' IDENTIFIED BY 'a-strong-password';
GRANT SELECT ON your_db.* TO 'mydatatalk'@'%';
FLUSH PRIVILEGES;

Snowflake

CREATE ROLE mydatatalk;
GRANT USAGE ON WAREHOUSE your_wh TO ROLE mydatatalk;
GRANT USAGE ON DATABASE your_db TO ROLE mydatatalk;
GRANT USAGE ON SCHEMA your_db.your_schema TO ROLE mydatatalk;
GRANT SELECT ON ALL TABLES IN SCHEMA your_db.your_schema TO ROLE mydatatalk;
GRANT SELECT ON FUTURE TABLES IN SCHEMA your_db.your_schema TO ROLE mydatatalk;
CREATE USER mydatatalk_svc PASSWORD = 'a-strong-password'
  DEFAULT_ROLE = mydatatalk;
GRANT ROLE mydatatalk TO USER mydatatalk_svc;

If your database isn't on the public internet

Most production databases aren't, and that's the right default. There are three ways through, in the order we'd recommend them:

  1. 1Allowlist our egress addresses. Open the database port to our outbound IP ranges only, keeping it closed to everything else. Get in touch for the current ranges before you configure this, since they're tied to our hosting and we'll tell you when they change.
  2. 2Point it at a read replica. A replica in a subnet you're comfortable exposing gives you an isolation boundary as well as a network one, and analytical questions shouldn't be competing with production traffic anyway.
  3. 3Start with an extract. Upload a CSV or Excel export and ask questions against that. It's the fastest way to evaluate whether the answers are any good before anyone opens a firewall rule.

Running somewhere that needs a private link or a tunnel instead? Tell us about your setup and we'll tell you honestly whether we can support it today.

Not ready to connect anything yet?

Every account can load a sample dataset and ask real questions against it first. No credentials, no firewall changes.

Start free

More on what we store and who can see it in the FAQ.