Retool_

An Appwrite native PostgreSQL database exposes a standard PostgreSQL connection, so Retool connects to it through the built-in PostgreSQL resource. Use the database hostname, generated database name, and credentials from Appwrite, then build queries, tables, and forms in Retool for dashboards and admin panels.

Choose credentials

The primary user is admin, and the database name is generated for each database. The connection string has this form: postgresql://admin:<password>@db-<hash>.<region>.appwrite.center:5432/<database>.

Use admin for initial setup or schema work because it owns the database and can run DDL. For a Retool app that only needs application-level access, create a narrower PostgreSQL role from the database Roles tab in the Console, then grant only the table privileges the app needs from the SQL editor or psql. For example, a dashboard role usually needs SELECT, while an admin tool may need SELECT, INSERT, UPDATE, and DELETE on specific tables.

Create the PostgreSQL resource

In Retool, go to Resources, click Create new > Resource, search for PostgreSQL, and select the PostgreSQL tile. Give the resource a clear Name and optional Description that identifies the Appwrite database and environment.

In Resource credentials, either paste the Appwrite connection string or fill in the fields manually:

In Advanced options, choose an outbound region if your Retool organization uses regional egress and you want the resource traffic to originate near your Appwrite database.

Enable SSL/TLS. Appwrite Cloud terminates TLS at the edge, and the certificate is signed by a public CA. If Retool shows Reject unauthorized, keep it enabled. If Retool shows Verification mode, choose Full verification. Leave CA certificate empty.

Click Test connection. If the test succeeds, click Create resource.

Pick the connection path

For most Retool apps, connect directly to PostgreSQL on port 5432. Retool uses prepared statements for PostgreSQL queries, and Appwrite's transaction-mode pooler does not preserve session-level state across statements. If you use the Appwrite connection pooler, configure it in session mode for Retool.

Allow Retool Cloud through the network

If you enabled an IP allowlist for the database, add the Retool Cloud egress addresses for the resource's outbound region. Retool's default outbound region is us-west-2, and Retool also documents eu-central-1 and ap-southeast-1 egress addresses. Retrieve the current list from Retool's IP address documentation instead of copying static addresses into your runbook.

If you leave the database allowlist open, rely on TLS plus database credentials and least-privilege roles to protect access.

Build an admin tool

After the resource is connected, create PostgreSQL queries in Retool and wire them to components:

• Use SQL mode for read queries that feed a Table, chart, or other display component.
• Use GUI mode actions such as Insert a record, Update an existing record, and Delete a record for forms and editable tables.
• Bind table edits to the Save changes event and refresh the read query after writes complete.
• Show a confirmation modal before delete actions.

Reference component values with Retool's {{ }} embedded expressions. Retool converts PostgreSQL queries to prepared statements by default, which separates values from SQL text and helps prevent SQL injection. Keep that protection enabled unless you have a specific, reviewed reason to disable it.

Use database roles as the last line of defense. A dashboard role with only SELECT cannot write even if a query is misconfigured. A data-entry role with table-level write privileges can create, update, and delete rows without also owning the schema.

Use a branch for staging

Branches are API-created, isolated copies of a PostgreSQL database with their own connection details. Create a branch for staging or preview work, fetch its connectionString, and configure a second Retool PostgreSQL resource against that branch. Delete the branch when the staging tool is no longer needed.

Related