Connectors

A connector is how data gets into Gaur. You point a connector at a source, it pulls the data in as a background job, and the result is one or more tables you can explore and build on.

This section has a page for every connector. Each one walks through creating the secret it needs and ingesting a table.

Gaur ingests data, it does not query your databases

This is worth being clear about up front. Gaur is not a query engine that runs against your live Postgres, MySQL, or data warehouse. A connector ingests a copy of the data into Gaur's own analytical storage, and every query, contract, and refresh runs against that copy.

That design is deliberate, and it works in your favour:

• Your source systems are never in the query path. Analytical queries, contract traffic, and AI-generated questions all hit Gaur's copy, never your production database. Reporting load can never slow down your application.
• No data warehouse to run. You do not need Snowflake, BigQuery, or a warehouse cluster behind Gaur. The analytical compute belongs to Gaur, so your infrastructure does not have to provision, scale, or operate it.
• A stable surface. Because Gaur holds its own copy, contracts stay consistent even as the source system changes. You control when fresh data comes in with refreshes.

The trade-off is that data is as fresh as its last ingestion or refresh, not live to the second. For analytical use that is the right trade, and refresh schedules keep the gap as small as you need.

The connectors

Most connectors pull: Gaur reaches out to the source on demand or on a schedule. The Webhook connector is the exception. It receives events that an external system pushes to a Gaur URL as they happen.

How ingestion works

Every connector follows the same shape.

Primary keys

Every ingestion accepts a primary_key: the column, or list of columns, that uniquely identifies a row in the table. It can be a single column like id, or a composite key like ["order_id", "line_no"].

The primary key is a property of the dataset, so you declare it at ingestion. Every contract that later joins this table can rely on it without restating it.

Two places the primary key matters:

• Contracts that join this table as a dimension lookup must reference the primary key in the join's on clause. A many_to_one join on a non-key column wouldn't actually be many-to-one, so Gaur requires the join to use the declared key. See Anatomy of a contract.
• Natural-language and AI surfaces (chat, MCP) use the primary key to tell identifier columns apart from look-alike attributes. A table with both customer_id and customer_unique_id is a common source of wrong joins for an LLM; the declared key removes the ambiguity. See Context.

For multi-file uploads, each file gets its own primary_key because each file becomes a separate table. See File upload.

Single table vs. multiple tables

Some sources hold one dataset, others hold many. Depending on the connector, an ingestion can produce a single table or multiple tables in one operation, for example several tables from one database.

Keeping data current

An ingested table is a snapshot taken at ingestion time. To keep it current, you run refreshes, on demand or on a schedule.

Need another connector?

Don't see the source you need? If you want Gaur to connect to another database, a SaaS application, or a custom system, reach out at hello@gaur.run. Tell us what you'd like to connect and what you're trying to do with it.

Our team will evaluate the request and get back to you. We're glad to build connectors that add value to Gaur, including ones you need for a specific use case.

Next