Data sources | Golden Reports Docs

A data source is a configured connection to a system Golden Reports reads from. It tells the platform where a system is, how to reach it, and what credentials to use. Reports never reference a data source directly - they go through a data context - but every data context ultimately resolves down to one or more data sources.

Where data sources live

Open Data sources in the Manager. The list shows every source registered in your organization, with:

The connector it uses (postgres, rest-api, csv, ...).
A health indicator - green if the engine could reach the source on the last check, red otherwise.
The number of data contexts that depend on it.
Audit metadata: who created it, when it was last updated, last health check time.

Click a source to edit it, run a health check on demand, or delete it (you can't delete a source still referenced by a data context - the Manager tells you which ones to update first).

Adding a data source

Click New in the data sources list.
Pick a connector type. The dropdown shows every connector currently installed in your organization. Connectors are managed through the Marketplace; see Extensibility model for how new ones are added.
Fill in the connector's configuration form. Each connector type asks for the connection details and credentials it needs - the exact fields are defined by the connector itself.
Click Test connection. The platform attempts a real round-trip to the source - open the connection, run a no-op query. You see green or you see an actionable error.
Save.

The saved configuration is encrypted at rest.

Connectors that ship with the platform

The default deployment includes:

PostgreSQL - covers most relational databases (including PostgreSQL-compatible offerings like Aurora, CockroachDB, and managed cloud Postgres).
REST API - for any JSON-over-HTTP endpoint. Supports bearer, basic, and custom-header authentication.
CSV - for file-shaped data. Accepts an HTTP(S) URL, an S3-compatible URL, or an uploaded asset.

Additional connectors (BigQuery, Snowflake, MongoDB, Stripe, Salesforce, etc.) are delivered as Marketplace extensions or built in-house. See Connectors.

Health checks

Each data source has two health states:

Last known health - recorded the last time someone ran a check. Shown as a coloured chip on the source.
Live health - what happens when you click Test connection right now.

The platform doesn't currently run scheduled health checks; the recorded health is updated whenever someone opens the source's detail page or runs an explicit test.

If a source goes red, every report that depends on it will fail at run time with a data source unreachable error. Errors returned to the caller are sanitized for safe display.

Tenancy and isolation

Data sources are organization-scoped. Register a source once and it is available to every workspace in the organization that's been granted access to it.

Access is governed by data access policies (see Sharing & permissions). A policy can restrict a source to specific workspaces, groups, or users - for example, "members of the Reporting team can use the production source; everyone else gets staging." This avoids the duplication you'd otherwise face when several teams need the same database with different governance.

Cross-organization sharing is intentionally not supported. Each organization is a hard tenant boundary; data sources, like every other resource, never cross it.

When to register a new source

A common question: should production-postgres be a single data source used by many contexts, or one source per context?

The right unit of granularity is per-credential, per-database. Concretely:

One source per physical database. Two databases on the same Postgres server are still two sources.
One source per credential. If you have a read-only role for finance and a separate read-only role for ops, those are two sources, even against the same database.
Not one source per query, table, or context. The data context layer is where query-level shaping happens.

This keeps the source list short and the credentials story honest.

Operational concerns

Connection pooling. Connectors keep a pool of live connections per data source for efficiency. High-throughput workloads may want explicit tuning via the connector's options.
Timeouts. Every query carries a per-query timeout. Queries that exceed it are cancelled and surface a timeout error.
Read-only by convention. The platform never issues writes through a connector. Don't grant write privileges to credentials you give it; treat the role as strictly read-only.

Define what a report can query: Data contexts.
See how query plans flow through the engine: The query engine.
Add a custom connector: Data source connectors.