PostgreSQL DESCRIBE TABLE: The psql \d Equivalent

If you came from MySQL, the first thing you try in PostgreSQL is DESCRIBE table_name; — and the answer is a syntax error:

ERROR:  syntax error at or near "DESCRIBE"
LINE 1: DESCRIBE users;

PostgreSQL does not have DESCRIBE TABLE. It is a MySQL/Oracle command. The canonical Stack Overflow thread (Q109325, ~1.7M views) gives the answer in one line: in psql, use \d table_name. Everything below is the "but I'm not in psql" half of the story.

The psql way — \d#

# \d users
                                  Table "public.users"
   Column   |          Type          | Collation | Nullable |       Default
------------+------------------------+-----------+----------+----------------------
 id         | integer                |           | not null | nextval('users_id_seq')
 email      | character varying(255) |           | not null |
 created_at | timestamp with time zone|           | not null | now()
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
    "users_email_key" UNIQUE CONSTRAINT, btree (email)

\d+ adds storage info, descriptions, and compression. \dt lists tables. \d with no argument lists everything in the schema. These are psql client commands — they are interpreted by the psql REPL, not by the PostgreSQL server, so they work only in a psql session.

The pure-SQL way — information_schema#

Every other client (Supabase SQL editor, Drizzle Studio, TablePlus, DataGrip, an ORM's raw query method) speaks SQL to the server, not psql. There, \d fails. Use the standard information schema instead:

SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'users'
ORDER BY ordinal_position;

This works everywhere — it is plain SQL against a standard view that every PostgreSQL database exposes. In Supabase specifically, you can run it in the SQL editor or just open the Table Editor in the dashboard.

Constraints and indexes#

\d already shows these in psql. In pure SQL:

-- constraints (primary key, foreign keys, checks, unique)
SELECT constraint_name, constraint_type
FROM information_schema.table_constraints
WHERE table_schema = 'public' AND table_name = 'users';
 
-- indexes (name + definition)
SELECT indexname, indexdef
FROM pg_indexes
WHERE schemaname = 'public' AND tablename = 'users';

Foreign keys in detail#

SELECT
  kcu.column_name,
  ccu.table_name  AS foreign_table,
  ccu.column_name AS foreign_column
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
  ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
  AND tc.table_name = 'users';

This is the query you reach for when debugging an RLS or foreign-key issue — pair it with the Supabase RLS debugging guide and the foreign-key constraint violation fix.

Common mistakes#

• Typing DESCRIBE in Supabase — it is not a PostgreSQL command. Use information_schema.columns or the Table Editor.
• Running \d from a JS/Python client — backslash commands are psql-only. supabase.from('...') and pg.query('\\d users') will both error.
• Forgetting table_schema — without it you get columns from every schema, including pg_catalog, which floods the result. Filter to public (or your target schema).
• Expecting information_schema to show storage details — it does not. For toast, fillfactor, or storage type, query pg_attribute / pg_class or use psql \d+.

Official references: PostgreSQL — The Information Schema, psql — backslash commands (\d).

Related Articles#

• Debugging Supabase RLS Issues
• Supabase Foreign Key Constraint Violation Fix
• SELECT First Row Per Group With DISTINCT ON in Postgres
• How to Get a Count in Supabase
• Supabase Slow Queries Fix
• How to Show Tables in PostgreSQL (psql + Supabase)
• Fix: psql: command not found (Install PostgreSQL Client)