Team Collaboration

In WhoDB, collaboration happens through a shared deployment, database-side access control, version control for SQL, and exports. This guide covers the patterns that work.

Run One Shared Deployment

Deploy a single WhoDB instance for the team instead of everyone running their own copy. Everyone gets the same version, the same connection profiles, and one place to secure and monitor.

Define the team's connections as environment-defined profiles on the deployment so they appear on the login page for everyone:

export WHODB_POSTGRES_1='{"alias":"staging","host":"staging-db.internal","user":"whodb_readonly","database":"myapp","port":"5432","password":"..."}'

This keeps connection details in deployment config (one source of truth) rather than in chat messages and wikis. See the Team Setup Guide for full deployment instructions and Database Connectivity for the profile format.

Use Per-User Database Accounts

Access control in WhoDB is the database's access control. Give each person their own database account scoped to what they actually need, rather than sharing one credential:

-- PostgreSQL: read-only account for an analyst
CREATE USER analyst_jane WITH PASSWORD 'unique_strong_password';
GRANT CONNECT ON DATABASE myapp TO analyst_jane;
GRANT USAGE ON SCHEMA public TO analyst_jane;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst_jane;

Why per-user accounts matter for collaboration:

• Least privilege: analysts get SELECT, developers get read-write on dev, only operators get production write access
• Attribution: database-native audit and statement logs show who ran what
• Clean offboarding: disable one account instead of rotating a shared password

See Access Control for detailed role setups.

Share Queries Through Version Control

WhoDB's Scratchpad state is stored per-browser — pages and cells are not visible to teammates. Use Scratchpad to build and test queries, then share the SQL itself through your normal channels:

1. Develop the query in Scratchpad against a development or staging database
2. Document it with a short header comment (purpose, dependencies, expected runtime)
3. Review it in a pull request like any other code — especially UPDATE/DELETE statements and anything touching production
4. Store it in a shared repository:

queries/
├── analytics/
│   └── daily_sales_summary.sql
├── reporting/
│   └── customer_invoices.sql
└── operational/
    └── health_checks.sql

Anyone who needs the query pastes it back into their own Scratchpad. Cell history in Scratchpad helps you recover your own recent SQL, but the repository is the team's memory.

Share Data Through Exports

For sharing results rather than queries, use WhoDB's export options:

• CSV or Excel from the data grid or query results — attach to tickets, drop into Slack, or feed into spreadsheets
• JSON Lines for records from sources like MongoDB, where supported
• Apply filters before exporting so the snapshot contains only what the discussion needs

When you share an export, include the SQL that produced it and when it was run — a CSV without provenance goes stale silently.

Collaboration Checklist

• One shared WhoDB deployment, secured per the Team Setup Guide
• Connections defined as environment profiles, secrets in a password manager
• Per-user database accounts with least-privilege grants
• Team query repository in version control, with review for destructive SQL
• Exports shared with the query and timestamp that produced them
• Accounts disabled and shared credentials rotated when someone leaves

Summary

Use WhoDB for inspection, querying, and repeatable exports; use database accounts for access control; and use your normal source control and review practices for long-lived team knowledge. The Scratchpad is each person's workbench — version control is the team's shared surface.