Supabase.

Supabase wraps PostgreSQL with Auth, Storage, and Edge Functions. Orchid connects directly to the database, giving you SQL access to every Supabase service through their underlying tables — no REST API in the way.

Requirements

• A Supabase project (free tier works).
• The database password — shown once when the project is created.
• Network reachability to the Supabase pooler endpoint.

Where to find your credentials

In your Supabase project: Project settings → Database → Connection info. You'll see two relevant blocks:

• Connection pooling (Session mode) — recommended for Orchid. Use port 6543.
• Direct connection — port 5432. Works but uses one connection per session.

Connect

1. Open Integrations → + Add connection → Supabase.
2. Paste the connection details:
   • Host — aws-0-<region>.pooler.supabase.com
   • Port — 6543 (pooler) or 5432 (direct)
   • Database — postgres
   • User — postgres.<project-ref>
   • Password — your database password
3. Make sure Require SSL is on.
4. Click Test connection → save.

Optional settings

Pinning to a specific schema

Set a default schema in the connection settings. public is the default; you can also point at auth, storage, or your own schemas without qualifying every table.

Querying Supabase services

Auth service tables

Supabase Auth stores users, sessions, and identities in the auth schema. These are fully readable from Orchid as long as your DB user has permission. Useful for analytics on sign-ups, MFA adoption, login frequency, dead accounts.

-- Daily new signups for the last 30 days
SELECT date_trunc('day', created_at) AS day, count(*) AS signups
FROM auth.users
WHERE created_at > now() - interval '30 days'
GROUP BY 1
ORDER BY 1;
      

-- Users who haven't logged in for 90+ days
SELECT id, email, last_sign_in_at
FROM auth.users
WHERE last_sign_in_at < now() - interval '90 days'
ORDER BY last_sign_in_at;
      

Storage service

Supabase Storage exposes its buckets and objects in the storage schema. Useful for object accounting, finding orphaned files, or building a storage dashboard.

-- Objects and total bytes per bucket
SELECT bucket_id,
       count(*)                                     AS objects,
       pg_size_pretty(sum((metadata->>'size')::bigint)) AS total_size
FROM storage.objects
GROUP BY bucket_id
ORDER BY sum((metadata->>'size')::bigint) DESC;
      

Edge Functions

Edge Functions don't expose runtime telemetry through the database, but if you instrument them to write into your own logs table on PostgreSQL, Orchid is the natural place to chart and query that. The Supabase dashboard's log explorer is the live tail; Orchid is for historical analysis.

Row Level Security (RLS)

RLS policies still apply at the database level — they aren't a Supabase-specific concept, just PostgreSQL. The default postgres user bypasses RLS (it's a superuser-equivalent), which is why you can read every row from Orchid by default.

For RLS-enforced queries that match a specific app role, create a separate database user in Supabase and use that user in Orchid:

-- Run this in the Supabase SQL editor
CREATE USER orchid_readonly WITH PASSWORD '...';
GRANT USAGE ON SCHEMA public TO orchid_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO orchid_readonly;

-- If you want this user to also be subject to RLS, do NOT grant BYPASSRLS.
-- Test with a known auth.uid() context:
SET request.jwt.claim.sub = '00000000-0000-0000-0000-000000000123';
SELECT * FROM your_rls_protected_table;
      

Then add a second Orchid connection using orchid_readonly instead of postgres. Toggle between connections per cell to validate that your policies match real app behavior.

Common gotchas

• "remaining connection slots are reserved" — direct connections (port 5432) are limited. Use the pooler (port 6543) for Orchid.
• SSL required — Supabase always requires SSL. Toggle it on in the connection settings.
• Project paused — Supabase pauses free-tier projects after 7 days of inactivity. Restart in the dashboard before reconnecting.
• IPv6 only — the Supabase pooler is IPv6. If your network blocks IPv6, the direct connection (port 5432) works over IPv4. Or use the IPv4 add-on if available on your plan.
• RLS appears to do nothing — you're probably connected as postgres and bypassing it. Use a non-superuser role to actually exercise policies.
• "permission denied for schema auth" — your DB user lacks USAGE on the auth schema. The default postgres user has it; custom roles don't until you grant.

Example queries

-- List public tables and approximate row counts
SELECT t.tablename, s.n_live_tup AS rows
FROM pg_tables t
LEFT JOIN pg_stat_user_tables s
  ON s.relname = t.tablename
WHERE t.schemaname = 'public'
ORDER BY s.n_live_tup DESC;
      

Where to go next

For more on writing SQL cells, see SQL cells.