PostgreSQL introspection is tricky (lessons from building a native client)

3 points

4 months ago

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 using 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.