The list-tables command shows every table in the connected ParadeDB/PostgreSQL database so you can explore its structure quickly.
Listing tables reveals what data is available, helps you avoid typos, and speeds up query design—especially in unfamiliar ParadeDB clusters.
Run the catalog view query below. It returns only base tables in the public
schema, which is where most ParadeDB objects live by default.
SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'public'
AND table_type = 'BASE TABLE';
Inside psql
, type \dt
. ParadeDB inherits this command from PostgreSQL, so it instantly lists all tables visible on your search_path.
Add the schema name to the meta-command (\dt analytics.*
) or widen the filter in information_schema.tables
by omitting table_schema
.
Filter out schemas that start with pg_
or are named information_schema
. The query below keeps only user-created tables.
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_schema NOT LIKE 'pg\_%'
AND table_schema <> 'information_schema';
Join pg_class
and pg_namespace
for lightweight estimations. Great for spotting large tables before running heavy analytics.
SELECT nspname AS schema,
relname AS table,
reltuples AS est_rows
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE relkind = 'r'
ORDER BY est_rows DESC;
Set search_path
consciously, keep a schema naming convention, and grant SELECT
privileges carefully so team-mates see only what they need.
Yes. Filter on table_owner = current_user
in information_schema.tables
or run \dt myuser.*
in psql.
ParadeDB keeps the standard PostgreSQL schemas, so the listing commands stay identical. Any ParadeDB-specific tables live in the paradedb
schema.
Absolutely. Both services expose the same system catalogs, so you can reuse every query shown in this guide.