Using a desktop client with Supabase

By Anil Gautam · Updated September 18, 2026

You can open your Supabase database in a desktop PostgreSQL client. For a typical GUI connection, start with the session pooler details in the dashboard. Use the database password and an encrypted connection, then check that you’ve opened the right project.

Which Supabase connection should a desktop client use?

Supabase recommends session pooling for third-party database tools. It supports IPv4 connections and prepared statements. Direct connections are also useful when your network supports the project's endpoint. Transaction pooling serves short-lived application requests and has session limitations, including no prepared statements. Copy the endpoint from the dashboard. Don’t guess the pooler hostname from the region name. Supabase connection guide.

Use a database password, not an API key

The database connection string and the project's HTTP API credentials belong to different interfaces. In plainDB, add a PostgreSQL connection and paste the string from Supabase's Connect dialog. Supply the database password separately if the string contains a placeholder. Keep the host, port and username together: a pooled username differs from the direct username. Our Supabase setup walkthrough covers the app controls.

Use the connection's SSL settings. Encryption and identity verification are different checks: PostgreSQL's verify-full mode verifies the certificate chain and hostname, while require primarily requires an encrypted connection. Use the appropriate CA certificate when configuring verification. PostgreSQL SSL documentation.

A desktop connection is not a test of your app's RLS

The desktop client runs as the database role you selected. An application request may run under a different role and carry a user's authentication context. PostgreSQL superusers and roles with BYPASSRLS bypass row security; table owners normally do too unless forced to follow it. Seeing a row in an administrative desktop connection therefore does not prove that an end user can see it. PostgreSQL row security documentation.

Keep a restricted connection for everyday inspection. Test application authorization through the actual application role and request path. A GUI's read-only setting is useful protection against mistakes, but database permissions define what a credential is allowed to do.

Start with a small, read-only check

After connecting, verify the database and role before opening application tables:

SELECT current_database(), current_user;

Then open a known schema, inspect a table's structure and browse a small page. For a synthetic example table named public.orders, a limited query might look like this; substitute your actual table and column names:

SELECT id, status, created_at
FROM public.orders
ORDER BY created_at DESC, id DESC
LIMIT 25;

If the connection fails, compare the exact copied endpoint before changing unrelated settings. An authentication error suggests a credential problem; an unreachable direct endpoint suggests a network problem; a pooler tenant error suggests a mismatch in the endpoint or username. Avoid repeatedly resetting a password for an endpoint that cannot be reached.

What plainDB adds to this workflow

plainDB provides a Supabase connection preset, table browsing, AND/OR filters, SQL tabs and review of staged table edits. It is a database client, not a replacement for Supabase Auth, Storage, Realtime or Edge Functions management. Review platform support before choosing a build: Mac and Windows share the database workflows, with platform-specific controls, credentials and AI setup.

Check plainDB availability