Skip to main content

Connections vs. connectors

Easy to confuse because the words are similar. They're different things.

Connector = the integration type​

A connector is a piece of code that knows how to talk to a particular kind of system. Honeyframe ships with a catalog of connectors:

  • Postgres connector — speaks the Postgres wire protocol
  • Snowflake connector — uses the Snowflake SDK
  • Google Sheets connector — uses the Sheets API + OAuth
  • S3 connector — uses AWS SDK
  • HTTP connector — generic REST API caller

A connector doesn't know about your Postgres instance or your S3 bucket. It just knows how to talk to "any Postgres" or "any S3".

Connectors are versioned and updated by the Honeyframe team (or by you if you author a plugin). Most users never directly think about connectors.

Connection = a configured instance of a connector​

A connection is a connector + your specific config: hostname, credentials, database name, etc.

You'd have:

  • One connection of type Postgres named "Production DWH" pointing at dwh-prod.example.com
  • A second connection of type Postgres named "Analytics replica" pointing at dwh-replica.example.com
  • A connection of type S3 named "Customer exports bucket"

A connection lives at the project or org level. Datasets reference connections; connections reference connectors.

Why the distinction matters​

It comes up in three places:

1. Credentials live on connections, not connectors​

You don't give your Postgres password to "the Postgres connector"; you give it to "Production DWH" specifically. Two connections of the same connector type have separate credentials, separate query history, separate audit trails.

2. Permissions are scoped to connections​

Granting a group access to "all Postgres data" is wrong shaped — the right grant is "access to Production DWH" (a specific connection). Different connections of the same type are typically different security domains.

3. Upgrading a connector affects all its connections​

When the Honeyframe team pushes a new version of the Postgres connector (better connection pooling, bug fix), every connection of type Postgres uses the new version on next reload. You don't get to pin individual connections to specific connector versions in normal operation; that's a plugin-author concern.

Common mistakes​

  • Calling a connection "the Postgres connector" — sloppy in conversation, but creates confusion when you try to manage 4 different Postgres connections
  • Sharing one connection across security domains — if "Sales" and "HR" both need Postgres data but shouldn't see each other's tables, give them separate connections (with separate DB users) rather than one shared connection. The DB user controls table-level visibility; Honeyframe permissions on a shared connection are coarser.
  • Treating connections as ephemeral — a connection is part of your data infrastructure. Don't recreate it just to change a hostname; edit the existing one (the connection ID stays stable, downstream datasets keep working).

See also​

  • Connectors (Documentation) — the catalog of supported connector types
  • Connection errors — diagnosing failures, where this distinction comes up
  • Plugins — authoring custom connectors