DEdebba·Feb 3, 2026Submission
PostgreSQL introspection is tricky (lessons from building a native client)
I’m building Tabularis, a native database client (Rust + Tauri).
MySQL support is in a good place, but PostgreSQL has been much harder to get right — not for performance, but for introspection.
Postgres “works”, but once you go beyond basic tables and columns, things get tricky fast.
Some gaps I’ve hit so far:
- Type system:
Arrays, JSON/JSONB, domains, custom types, ranges, geometric types — most clients either flatten them to text or handle them inconsistently.
- Schema introspection:
information_schema only goes so far.
pg_catalog is powerful but subtle.
Triggers, functions, partitioned tables, inheritance, materialized views all require special handling.
- Postgres-specific UX:
CTE-heavy queries, EXPLAIN ANALYZE output, extensions like PostGIS / pgvector — these don’t map cleanly to generic DB abstractions.
I’m currently u
Read the rest
sing SQLx and a mix of information_schema + pg_catalog queries, but I’m sure there are better patterns I’m missing.
I’d love feedback from people who:
- Have written serious Postgres introspection queries
- Have opinions on how Postgres clients should represent schemas and types
- Have been frustrated by existing Postgres GUIs
Repo (Apache 2.0): https://github.com/debba/tabularis
Happy to learn, iterate, and fix wrong assumptions.