I wanted two things and could not find them together:
1. A critical review of a (my) PostgreSQL schema.
2. A visualiser that shows how (possibly) hundreds of tables connect.
Nothing did both, so I built it....in a mid-Late 2026 moment (I know what you're thinking).
Anyway, then I ran it on the GitLab schema... cause why not right - its opensource? (nothing against gitlab btw, used it for years without a hitch, even hosted it myself)
I found missing keys, unindexed foreign keys, junction tables that allow duplicates, money in floats, relationships whose cardinality does not match what everyone believes, and a structural visualiser good enough to understand the relationships and the coupling in a schema of a few hundred tables.
So I built both into one tool, called it archlens-postgres, and to see whether it holds up I ran it over seven open-source products whose schemas are public: Temporal, Miniflux, Listmonk, Matrix Synapse, Sourcegraph, Cal.com and GitLab.
The review half parses the DDL with libpg_query (PostgreSQL's own parser as WebAssembly) and runs 23 deterministic checks; each finding carries the cost,the fix and usually the SQL.
The visual half is a 3D explorer: one island per domain, every foreign key an arc, click any table or arc for its detail, mute the sheaf into the hub table with one click.
GitLab is 1,429 tables and 1,861 foreign keys; its projects table is referenced by 371 others, namespaces by 353. You can see that coupling in about two seconds in the explorer and not at all in a diagram.
Synapse: 109 of the 137 tables in its published full schema have no primary key.
Sourcegraph: 270 foreign keys with no index. 157 of them are the same tenant_id column, added to every table by their multi-tenancy work.
Cal.com: 205 timestamps without time zone (Prisma's default), one price stored as a float.
Temporal: zero foreign keys across 38 tables, by design.
TO BE CLEAR: I am not trying to fatshame or doxx any OSS project here here, just calling it how the tool (for better or worse) found it.
Telling the deliberate findings from the accidents is also hard.
The tool's answer is a narratives file: a human records "this is intended, here's why" once, and the next run treats it as a claim to check rather than a finding to repeat.
It's packaged as a Claude Code plugin because that judgment half is where an AI pair helps; the script runs on its own without it.
Schemas are fetched at pinned commits from each project's own repository; nothing is committed or edited by hand.
I wanted two things and could not find them together:
1. A critical review of a (my) PostgreSQL schema. 2. A visualiser that shows how (possibly) hundreds of tables connect.
Nothing did both, so I built it....in a mid-Late 2026 moment (I know what you're thinking).
Anyway, then I ran it on the GitLab schema... cause why not right - its opensource? (nothing against gitlab btw, used it for years without a hitch, even hosted it myself)
I found missing keys, unindexed foreign keys, junction tables that allow duplicates, money in floats, relationships whose cardinality does not match what everyone believes, and a structural visualiser good enough to understand the relationships and the coupling in a schema of a few hundred tables.
So I built both into one tool, called it archlens-postgres, and to see whether it holds up I ran it over seven open-source products whose schemas are public: Temporal, Miniflux, Listmonk, Matrix Synapse, Sourcegraph, Cal.com and GitLab.
The review half parses the DDL with libpg_query (PostgreSQL's own parser as WebAssembly) and runs 23 deterministic checks; each finding carries the cost,the fix and usually the SQL. The visual half is a 3D explorer: one island per domain, every foreign key an arc, click any table or arc for its detail, mute the sheaf into the hub table with one click.
GitLab is 1,429 tables and 1,861 foreign keys; its projects table is referenced by 371 others, namespaces by 353. You can see that coupling in about two seconds in the explorer and not at all in a diagram.
https://greensill.net/postgres-schema-gallery/gitlab/schema-...
Some of what the review found:
Synapse: 109 of the 137 tables in its published full schema have no primary key.
Sourcegraph: 270 foreign keys with no index. 157 of them are the same tenant_id column, added to every table by their multi-tenancy work.
Cal.com: 205 timestamps without time zone (Prisma's default), one price stored as a float.
Temporal: zero foreign keys across 38 tables, by design.
TO BE CLEAR: I am not trying to fatshame or doxx any OSS project here here, just calling it how the tool (for better or worse) found it.
Telling the deliberate findings from the accidents is also hard.
The tool's answer is a narratives file: a human records "this is intended, here's why" once, and the next run treats it as a claim to check rather than a finding to repeat.
It's packaged as a Claude Code plugin because that judgment half is where an AI pair helps; the script runs on its own without it.
Schemas are fetched at pinned commits from each project's own repository; nothing is committed or edited by hand.
The gallery's build is at:
https://github.com/greenstevester/postgres-schema-gallery
and the reviewer at
https://github.com/greenstevester/archlens-postgres (both MIT).
Which schema should go in next? It needs a plain-SQL PostgreSQL schema in the repo, or a Prisma schema; the build can emit SQL from that.