Shared connections.
Let your whole team query the same database without everyone juggling their own credentials. An org owner builds a catalog of data sources, decides which teams see each one, and teams adopt the ones they need.
The connection catalog
Shared connections live on the web dashboard at orchidide.com/orgs, on the org page’s Connections tab — visible to owners and admins only. There, an owner or admin builds a catalog of data sources the organization owns, grants each one to specific teams, and lets those teams adopt what they need. Supported types:
- PostgreSQL
- MySQL
- BigQuery
- Snowflake
- Supabase
- SQLite
Shared vs. template
Every connection is one of two modes, and they behave very differently.
- Shared credential — the org stores one service-account credential, encrypted. Members query through it and never see the password. Best when there’s a single service account everyone should use.
- Template — config only: host, port, database. No credential is stored in the cloud. Each person supplies their own credential locally. Best when people should authenticate as themselves. SQLite is file-based, so it is template-only.
Either way, credentials are write-only and the encrypted vault is never readable through the database — see Secrets & env vars for exactly how that works.
Who can see it: per-team visibility
An owner or admin picks which teams may see and adopt each connection. Visibility is the access control — there’s no separate permission switch. Members of a team without visibility can’t use the connection at all. Remove a team from a connection’s visibility and that team loses it: its adopted copy goes away too.
Org owner creates → warehouse (shared credential)
grants visibility → Analytics team, Growth team
Analytics adopts → the team can now query it
Growth not adopted → visible, available, not yet in useAdopting a connection
A team lead — or an org owner/admin — adopts a connection the org made visible to the team, or creates the team’s own. The choice that matters most is cascade, which decides whether the team tracks the org’s version or keeps its own.
- Cascade on (live reference) — the org’s later edits to the host or credential flow down to every adopting team automatically.
- Cascade off (snapshot) — the team gets a private copy at adopt time. Later org edits don’t reach it.
Cascade is set when the connection is created and can’t be changed later. Choose deliberately: pick cascade on when you want one source of truth the org keeps current, and cascade off when a team needs a stable copy that won’t shift under it.
Running queries
The actual analysis happens in the Orchid desktop app. When a teammate runs a query against a shared connection, the credential is handed to their desktop app just for that query and is never displayed — they query through it without ever seeing the password. Viewers can’t check out a credential at all.
Where to next
- Secrets & env vars — how the encrypted vault and write-only secrets work.
- Teams — who belongs where, and team roles.
- Sharing projects — grant a published project to an org or team.