Why QoreDB blocks mutations in production by default

A developer connected to a production database can, in a second of inattention, run a DROP TABLE or a DELETE with no WHERE. Tools like DBeaver or pgAdmin let this kind of operation through without blinking. QoreDB takes the opposite stance: by default, destructive mutations are blocked in production.

This is not a simple UI warning. The check is done on the backend, in Rust, before any query at all is passed to the database engine.

Every connection has an environment

In QoreDB, each connection is associated with an environment: Development, Staging, or Production. This choice is made when the connection is created and stored in the encrypted vault, alongside the credentials. The environment is not a cosmetic label. It governs the backend's behavior for the entire duration of the session.

The Rust code converts the environment string into a typed enum (Development, Staging, Production) as soon as the command is received. This classification is then injected into the context of every intercepted query. Strong typing guarantees that no query can be executed without a known environment.

On the interface side, the Production environment triggers a distinct visual theme with red borders in the status bar. This permanent feedback reminds the developer of the context they are working in. But the real safeguard lies elsewhere.

SQL analysis before execution

Before sending a query to the database engine, QoreDB analyzes it with sqlparser, an SQL parser written in Rust. The parser produces an AST (abstract syntax tree) that the sql_safety.rs module inspects to classify the query.

Two properties are extracted from each statement. First, is_mutation: does the query modify data? An INSERT, UPDATE, DELETE, or SELECT INTO is a mutation. A SELECT, SHOW, or EXPLAIN is not. Second, is_dangerous: is the query potentially destructive? A DROP, TRUNCATE, ALTER, or an UPDATE/DELETE without a WHERE clause falls into this category.

The parser uses the SQL dialect corresponding to the active driver. PostgreSQL, MySQL, DuckDB, and SQL Server each have their own dedicated dialect, which avoids false positives caused by syntax differences between engines.

The Safety Engine and its built-in rules

The result of the SQL analysis feeds the Safety Engine, the central prevention component. This rule engine evaluates each query before execution by checking it against a set of rules, some built in, others defined by the user.

The built-in rules cover the most common cases. In a Production environment, DROP and TRUNCATE are blocked. DELETEs trigger a confirmation request. UPDATE and DELETE without a WHERE require explicit confirmation, including in Staging. ALTERs generate a warning.

Each rule defines a triplet: the environments concerned, the operation types targeted, and the action to apply (Block, RequireConfirmation, or Warn). Some rules add a regex pattern to refine the targeting, for example to detect an UPDATE without WHERE independently of the AST parser.

Read-only mode as an additional lock

Independently of the Safety Engine, each connection can be configured in read-only mode. This mode is checked on the backend even before the query is analyzed. If the connection is read-only, any mutation is rejected immediately, regardless of the environment.

This check happens in every mutation Tauri command (insert_row, update_row, delete_row). The code first checks the read_only flag via the session manager, then the driver's capabilities, and finally the safety rules. This triple control ensures that no execution path can bypass the protection.

Customizable rules and environment-variable overrides

The built-in rules can be disabled individually, and custom rules can be added. Each custom rule defines its own regex pattern, its target environments, and its action. The engine compiles and caches the regexes to avoid recompiling them on every query.

For managed deployments, two environment variables make it possible to enforce the security policy at the system level. QOREDB_PROD_BLOCK_DANGEROUS blocks all dangerous queries in production, with no possibility of confirmation. QOREDB_PROD_REQUIRE_CONFIRMATION requires explicit confirmation. These variables override the local configuration, which allows an administrator to guarantee a uniform policy across all installations.

In practice: what happens when you run a DROP in production

Let's take a concrete scenario. A developer is connected to a PostgreSQL database marked Production. They type DROP TABLE users in the SQL editor and run it.

The backend receives the command. The sql_safety module parses the query with the PostgreSQL dialect and detects a DROP statement: is_mutation and is_dangerous are both true. The execution context is built with the Production environment, the Drop operation, and the acknowledged flag set to false.

The Safety Engine evaluates its rules in order. The first applicable rule is "Block DROP in Production". Its action is Block. The query is rejected before reaching the PostgreSQL driver. The entry is recorded in the audit log with the blocked flag set to true.

The user sees an explicit error message in the interface. No ambiguous popup, no "are you sure?". The query is simply blocked.

Protecting production environments in QoreDB rests on a chain of backend-side checks: typed environment classification, per-dialect SQL parsing, a rule engine with graduated actions, an independent read-only mode, and overrides through system environment variables. Every link is unit tested. The goal is simple: to make an accident in production structurally impossible, not merely improbable.