Projects

Group related databases by the work they support, rather than hoping the server name tells the whole story.

A Project gathers the databases behind one piece of work, whether that is a product, a migration, or an analysis. It is the structural twin of a Client, with the same name, color, icon, and safety fields.

Why it is a separate dimension

Client and Project are independent: a connection can have both, either, or neither. A client answers whose database it is; a project answers what work it supports - and the two genuinely do not nest. One migration can span three customers' databases, and one customer can have five projects running at once. Making them separate fields is what lets you group the explorer either way without filing the same connection twice.

connection  acme-prod      client=Acme     project=Billing v2
connection  globex-prod    client=Globex   project=Billing v2
connection  acme-report    client=Acme     project=Q3 analysis
-- group by client  → Acme (2), Globex (1)
-- group by project → Billing v2 (2), Q3 analysis (1)

Using them

• A typed project name autocompletes from the ones you already use, so a stray “Billing V2” does not quietly become a second group.
• A new name is registered on save, which is what lets it carry a color, an icon, and safety settings of its own.
• Safety set on a project applies to every connection in it and can only tighten - see Set once, inherit everywhere. A project is a good home for “everything in this migration is rollback-wrapped until we go live”.

SQLly

Group the explorer by project from the sidebar header to see work-by-work instead of owner-by-owner. See also Environments, the third independent dimension.