Loading

Connecting to a Data Source

External data sources let the platform read — and where you allow it, write — data that lives somewhere else, without copying it in by hand.

Where to find it

Architect Panel → Integration & Connections:

  • Data Sources — the console — connect, test, map objects
  • Data Source Sync History — what each sync run did
  • Data Source Writeback Queue — changes queued to go back out

Architect Panel → Automation:

  • Tasks — External Data Source Sync and Writeback, both every 5 minutes

The nine drivers

  • PostgreSQL, MySQL / MariaDB, Microsoft SQL Server / Azure SQL — direct SQL connections.
  • MongoDB — via a connection URI.
  • Snowflake — with key-pair authentication.
  • Salesforce — by connected app or username-password flow.
  • GraphQL endpoint and REST API — for services rather than databases.
  • Google Sheets — via a service account.

Despite the section being called external databases, more than half of these are not databases. A REST API or a spreadsheet can be mapped onto a datastore exactly as a SQL table can.

Each driver declares its own fields

Rather than one generic connection string, every driver publishes the fields it actually needs — host, port, database and SSL mode for PostgreSQL; account, warehouse, role and a private key for Snowflake; a spreadsheet ID and a service account key for Sheets.

This is why the form changes when you change the driver, and why the prompts match the vocabulary of the system you are connecting to rather than a lowest common denominator.

Credentials are held encrypted

Every credential field — passwords, tokens, client secrets, private keys, connection URIs — is stored encrypted rather than in plain text.

Use a purpose-made account

Create an account on the remote system for this connection alone, with the narrowest rights that do the job: read-only unless you are writing back, and scoped to the specific tables or objects you need.

Reusing a person's credentials means the integration breaks when they leave, and it makes the remote system's audit trail attribute the platform's activity to them.

TLS

Each driver exposes its own transport security setting, and there is a certificate verification option on the connection. Turn verification on. Encryption without verification protects against passive interception but not against connecting to the wrong server, which is the harder problem.

Limits

Set the query timeout and the maximum live rows deliberately. They exist so a slow or enormous remote query degrades one screen rather than the platform, and the defaults are a starting point rather than an answer.

Test before mapping

The connection records its last test, the resulting status and any error. Get a clean test before you map a single object — every subsequent problem is easier to diagnose when the connection itself is known good.

Worked example

A finance team connects a read-only PostgreSQL account to their reporting warehouse, with SSL mode set to verify-full and a 15-second timeout. The test succeeds, the DBA confirms the account can see only two schemas, and object mapping starts from there.

Recommendations

  • One purpose-made remote account per connection, read-only by default.
  • Enable certificate verification.
  • Set timeouts and row limits rather than accepting defaults.
  • Get a clean test first, always.