Postgres gui for queries should provide options to strip out the schema

💬 Queries and Resources
1

:rotating_light: Feature Request: Prevent or Warn Against Hardcoded Schemas in Query Builder

We’re using Retool to power internal tools for multiple user groups (installers, CSRs, partners), with PostgreSQL environments split by schema (pw_prod, pw_stage, etc.) and controlled via search_path.

However — the Query Builder hardcodes the schema name (e.g., pw_prod.users) into every query. This completely bypasses the search_path mechanism, and breaks all of our efforts to maintain:

• :repeat: Environment parity (prod vs. stage)

• :wrench: Schema-level portability

• :soap: Code reuse across apps

• :shield: Consistent security context

• :mag: App portability and reviewability

:brick: The Problem

  1. Query Builder forcibly hardcodes schema names , e.g., pw_prod.users, with no way to opt out .

  2. Even when we configure a search_path in the Retool resource settings, it is not respected inside GUI-built queries.

  3. The only way we got it working was to set a default search_path at the database level (per user role) in Postgres — which defeats the purpose of environment-level flexibility in Retool.

  4. There is:

• :x: No “Convert to SQL” for Postgres queries

• :x: No preview of generated SQL

• :x: No schema-awareness toggle in the GUI

• :x: No way to detect this misuse across apps

:white_check_mark: What We Need

At a minimum, we need an option in the Postgres resource settings:

:ballot_box_with_check: “Enforce use of search_path (disallow hardcoded schemas in Query Builder)”

Also helpful:

• :warning: Warning or confirmation when Query Builder auto-inserts schema names

• :white_check_mark: “Convert to SQL” for all query types

• :mag: A way to inspect generated SQL from GUI queries

• :test_tube: Linter/audit tooling to detect and flag schema-qualified table references

:pray: Why This Matters

Retool is awesome for quickly building internal tools, but once you’re supporting multi-environment deployments, shared resources, and schema-based access control, these seemingly small limitations cause serious headaches.

We’ve had to enforce SQL-only development, audit apps for schema references, and shift query logic to the DB level — all to work around something that feels like it should be configurable.

1 Like
2

Hi David,

Have you considered using separate databases per environment instead of schemas like pw_prod and pw_stage? While your approach can work, using schemas to separate environments can introduce risks, like accidental cross-access or confusing query behavior, especially in Retool, where schema names are prepended automatically.

If you're using a platform like Neon, what Retool db uses under the hood, you might consider using branches to quickly duplicate your production database structure for staging or testing. It keeps environments isolated and easier to manage long term.

Neon is what Retool db is under the hood.

Just a thought — hope that helps!

1 Like