DataSpell read-only mode enforcement when testing against non-production databases

DataSpell provides a read-only toggle per data source that blocks DML statements in the IDE, yet the documentation notes this guard operates only on the client side and does not translate to server-level permissions. When configuring a dedicated test database (for example, a PostgreSQL instance spun up in CI) to avoid production credentials, the read-only flag can be flipped accidentally or bypassed by editing the connection, leaving the test database vulnerable to unintended writes.

The goal is to run exploratory queries and notebook SQL cells against a realistic dialect without risking data mutation, while still exercising production-like features such as stored procedures or advisory locks that SQLite cannot replicate. Constraints include the need for zero production credentials, CI-friendly setup, and assurance that neither a misclick nor a notebook cell can persist changes.

Does DataSpell offer a mechanism to bind the read-only intent to the database connection itself—such as opening the session with SET TRANSACTION READ ONLY or using a restricted database role—so the enforcement survives IDE restarts and connection edits? Which configuration approach ensures that a test database receives the same dialect fidelity as production while remaining write-protected at the server level?