Skip to main content
TablePro can manage the users and roles on a server and the privileges they hold. Changes are staged, so nothing reaches the server until you review the SQL and apply it. Available on MySQL, MariaDB, and PostgreSQL connections. Open it from View > Users & Roles. The command is disabled on connections whose driver does not support it.
Users and Roles tab with the account list, object tree, and privilege checklist

Users & Roles: accounts on the left, objects in the middle, privileges on the right

​
The layout

The tab has three panes:
  • Users and roles on the left. Filter, sort, and select an account. + and - below the list create and drop accounts.
  • Objects in the middle: the server, its databases, and, as you expand them, schemas, tables, and columns. The Privileges column tells you what the selected account has on each object without having to click it.
  • Privileges on the right: the privileges that can actually be granted on the object you selected, grouped into Data, Structure, Administration, and Dynamic.
Select several objects of the same kind to grant a privilege on all of them at once.

​
Effective privileges

A checkbox tells you what is granted directly on that object. The Effective column tells you where access actually comes from:
  • Inherited from role means the account holds the privilege through a role it is a member of. PostgreSQL roles are followed transitively. If the account has NOINHERIT, the privilege only applies after SET ROLE, and TablePro says so.
  • Granted on object means a privilege on a parent object already covers this one. This is engine-specific: on MySQL a database-level grant covers the tables inside it, while on PostgreSQL it does not. TablePro asks the driver rather than guessing.

​
Granting and revoking

Toggling a checkbox stages a change. The account, the object, and the privilege each show that they have unsaved edits, so a change is findable even in a server with hundreds of tables. Changes are always a diff. Unchecking a box you just checked cancels out instead of generating a redundant REVOKE, and a privilege that was grantable to others stays grantable. To give an account the same privileges as another, choose Copy Privileges From in the account’s context menu. The copied grants are staged like any other change.

​
Account attributes

The detail pane has a Privileges / Attributes switch. The Attributes form edits the account itself:
  • Whether the account can log in.
  • Role attributes such as SUPERUSER or CREATEDB on PostgreSQL.
  • Role membership, where the engine has roles: Member of lists the account’s roles, and Edit opens a checklist.
  • The connection limit.
Attribute edits are staged and applied with everything else.

​
Passwords

Change Password, in the account’s context menu and on the Attributes form, sets a new password. The sheet has a Generate button that produces a random 20-character password and reveals it so you can copy it somewhere safe. The password is staged until you apply. Statements that carry a password, such as CREATE USER and ALTER USER, are never written to query history, which is stored unencrypted on disk.

​
Applying changes

The bar at the bottom counts staged changes. Discard throws the whole staged set away. Review & Apply shows the exact statements, including the ones that remove access. From the review sheet you can Copy All, open the SQL in a query editor, or Execute it. On PostgreSQL the statements run in a single transaction and roll back together if one fails. MySQL commits user management statements implicitly, so a transaction cannot undo them; if one fails, TablePro shows the error and how many statements had already been applied. After a successful apply, TablePro re-reads the server so the tab reflects what is actually granted. Changes run through the same safeguards as any other write: a read-only connection blocks them, and Safe Mode asks for confirmation or authentication as configured.
If a change would remove access for the account your connection is using, TablePro warns you in the review sheet before the SQL runs. It does not block the change, since revoking your own admin privileges can be deliberate.

​
Dropping an account

Select it and press Delete, or use -, or the context menu. The drop is staged and struck through, and Cmd+Z undoes it. Nothing runs until you apply. On PostgreSQL, a role that owns objects cannot simply be dropped. TablePro detects this and asks whether to reassign the owned objects to another role or drop them, generating REASSIGN OWNED or DROP OWNED alongside the DROP ROLE.
REASSIGN OWNED and DROP OWNED only affect the database you are connected to, plus shared objects. A role that owns objects in several databases needs the same step run in each. This is PostgreSQL behavior, not a TablePro limitation.

​
What PostgreSQL cannot show you

PostgreSQL stores schema, table, and column privileges per database and cannot read them for a database it is not connected to. Those databases still appear, still show their cluster-wide database-level grants, and are marked as not browsable. They are never shown as though the account had no privileges there. MySQL has no such restriction.

​
What is not covered

  • Editing WITH GRANT OPTION. It is displayed, and never silently removed, but it is not editable.
  • ALTER DEFAULT PRIVILEGES and GRANT ... ON ALL TABLES IN SCHEMA.
  • MySQL 8 roles. MySQL accounts are managed as users.
  • Renaming an account.