Security

✓ functional

Users, roles, membership, and access for the selected database.

Database-level security for the selected database: its users, their role membership, and the object and schema permissions that shape what each one can touch. Same master-list-plus-editor dialog as the server version, scoped one level down.

Why this is separate from server security

A login is not a user. On SQL Server, a login gets you onto the instance; a user is that login's identity inside one database, with its own roles and grants. They can drift apart - an orphaned user whose login was dropped, a login with no user in the database it needs. Keeping the two panes separate is what makes that distinction visible instead of something you discover from a permission error.

What you edit here

Users - with a database picker at the top, a login dropdown when creating one, and a default-schema field.
Database roles - membership as a checklist, including the fixed roles (db_datareader, db_datawriter, db_owner, and the rest) alongside your own.
Permissions - what has been granted on schemas and objects within this database.

Nothing runs until you apply

Edits are diffed against the baseline that was loaded and rendered as an exact batch under Statements to apply - CREATE USER, role grants, permission changes - shown verbatim before the Apply (N) button, which counts them. Read them, copy them into a change request, or close the dialog and nothing has happened. A connection marked production read-only disables Apply entirely.

SQLly database security dialog — Database Security: users, roles, and the permissions granted within one database.

Per-engine shape follows the engine: PostgreSQL's roles and schema grants, and MySQL's 'user'@'host' accounts with per-database privileges, are handled in the terms those engines actually use rather than being forced into a SQL Server mould.