How do I set up permissions so that some users can execute queries but not modify the SQL logic?

galaxy.io" target="_blank" id="">Galaxy lets you assign a run-only role (Viewer) that can execute approved queries while its built-in RBAC and version control block any edits to the underlying SQL.

Why separate run and edit privileges?

Protecting production SQL logic from accidental or malicious changes is a core data-governance practice. Granting run-only access lets stakeholders answer questions without risking broken queries, drifted metrics, or security incidents.

How does Galaxy handle run-only permissions?

Galaxy ships with role-based galaxy.io/features/collaboration" target="_blank" id="">access control (RBAC) tailored for SQL collaboration:

Viewer role (run-only)

- Can execute any query shared with them in a Workspace or Collection.
- Cannot change, overwrite, or save SQL.
- Attempts to edit open the editor in read-only mode.
- Every run is logged in audit history for easy compliance review.

Editor and Owner roles

- Editor can run, save, and modify queries but cannot change workspace settings.
- Owner has full administrative rights, including managing integrations, secrets, and roles.

Because Galaxy versions every change, even Owners cannot silently alter endorsed queries without leaving an immutable diff.

Step-by-step setup in Galaxy

1. Create or identify a Viewer role

Navigate to Workspace Settings → Roles and confirm the default Viewer role has only execute_query privileges.

2. Add users who need run-only access

Invite teammates via email and assign them the Viewer role on join. They inherit run-only rights immediately.

3. Curate approved queries

Place production-ready SQL in a Collection and click Endorse. Endorsed queries surface in search and carry a trust badge so Viewers know what is safe to run.

4. Verify with audit logs

Run a quick query as a Viewer, then open Workspace Settings → Audit Log to confirm the execution was captured and no edit events appear.

Database-level hardening (PostgreSQL example)

Even outside Galaxy, apply least privilege on the database:

-- Create a run-only role
CREATE ROLE query_runner;

-- Grant read access but no DDL/DML
GRANT CONNECT ON DATABASE prod TO query_runner;
GRANT USAGE ON SCHEMA public TO query_runner;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO query_runner;
REVOKE INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public FROM query_runner;

-- OPTIONAL: allow stored procedure execution
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO query_runner;


Map each Galaxy Viewer to query_runner via a database-side user or SCIM integration. The combination of database and Galaxy controls yields defense in depth.

Best practices to keep SQL logic safe

- Version every query in Galaxy or Git.
- Use parameterized queries to prevent ad-hoc edits.
- Schedule routine audits of role grants.
- Re-endorse queries after schema changes to maintain trust.

With Galaxy’s run-only role plus database RBAC, you can democratize data access in 2025 and beyond without compromising the integrity of your SQL.