QoreDB LogoQoreDB
Back to blog
ProduitTechnical journal

The Interactive ER Diagram: Visualizing a Relational Schema

A database client must show the relationships between tables as clearly as their content. When you're discovering an unfamiliar schema, reading lists of columns isn't enough: you need to see what points to what, and how the entities fit together. The entity-relationship diagram…

Raphaël – Creator of QoreDBRaphaël – Creator of QoreDB
5 min readUpdated Jul 18, 2026
The Interactive ER Diagram: Visualizing a Relational Schema

A database client must show the relationships between tables as clearly as their content. When you're discovering an unfamiliar schema, reading lists of columns isn't enough: you need to see what points to what, and how the entities fit together. The entity-relationship diagram is the classic tool for this kind of reading, and QoreDB integrates it directly into the Browser.

The main constraint is honesty. An ER diagram must not invent relationships that don't exist in the database, nor hide ones that do. QoreDB builds its diagram from the native metadata exposed by the engine, with no magic heuristics, and lets the user enrich that graph with virtual relations when the original schema doesn't express them.

Building the diagram from existing metadata

The source of truth is the engine's catalog. For each table, QoreDB queries its schema via getTableSchema: columns, primary key, declared foreign keys, indexes. This data comes from each driver's standard functions: information_schema and pg_catalog for PostgreSQL, the equivalent views for MySQL, the Tiberius metadata for SQL Server. No inference, no data scan, no statistical model to guess missing relationships.

Tables are loaded in parallel by a small pool of workers, six at a time. On a database with a hundred tables, this model avoids sequential loading while keeping the engine under controlled pressure. A progress indicator (tables loaded out of total) gives visual feedback during the operation, and the view initializes as soon as the schema is ready.

SVG rendering driven by React

The canvas is built in two layers. Tables are absolutely positioned HTML elements, which keeps the text selectable, allows Tailwind styling, and enables fine-grained handling of pointer events. The links between tables are drawn in SVG as cubic Bézier curves, whose control points depend on the horizontal distance between nodes. The result: connections that read well even when the tables are close together or far apart.

The layout is simple and deterministic. Tables are distributed across a maximum of four columns, each new table going into the least-filled column. This greedy placement produces a balanced arrangement without needing an expensive force-directed algorithm in the browser. On dense databases, readability is preserved by combining zoom with isolation earlier in the navigation.

By default, each table shows at most eight columns, prioritizing the primary key, the columns participating in outgoing foreign keys, and those referenced from other tables. An overflow counter indicates how many additional columns exist, and a click on the table expands it to show them all. This logic is carried by the buildDisplayColumns function, which keeps the structurally important information visible without saturating the screen.

Isolating a table to understand its neighborhood

On a medium-sized schema, the global view quickly becomes too dense to be usable. QoreDB provides an isolation mode: you select a table, and the diagram then shows only that table and the ones directly linked by an incoming or outgoing foreign key. The rest disappears until you switch back to the global view.

This mode is implemented as a filter over the full graph, not as a layout recomputation. The reference positions stay stable from one isolation to the next, so the user keeps their visual bearings when switching from a table to its neighbors. It's a deliberate trade-off: you lose some compactness in favor of visual consistency between views.

Native and virtual foreign keys

Not all databases have their relationships declared. This is common in legacy schemas, or in MongoDB, where the notion of a foreign key doesn't exist at the engine level. QoreDB distinguishes two types of edges in the diagram.

Native foreign keys, surfaced by the catalog, are drawn as solid lines. Virtual foreign keys, defined by the user through the Virtual Relations panel, are drawn as purple dashed lines. The visual difference is immediate: at any moment you know whether a relationship is guaranteed by the engine or declared client-side to ease navigation.

This separation matters for reading the schema. A virtual relation is never promoted to the status of a native constraint. It remains a local view, persisted in the QoreDB configuration, and in no way alters the underlying database. The diagram reflects two clearly identifiable levels of reality: that of the engine and that of the usage context.

The interaction follows the conventions of graphical editors. Scroll wheel to pan, Ctrl or Cmd combined with the wheel to zoom around the cursor, click-and-drag to move the view. A Fit button automatically reframes on the entire graph; Reset returns to 1:1 zoom.

Searching by table name highlights the matches by dimming the opacity of the others, and a Focus button centers the diagram on the first table found. Combined with isolation, this toolset is enough to navigate a hundred-table schema without getting lost, starting either from a known name or from a table spotted visually.

What it looks like in real use

The typical flow on an unfamiliar database is straightforward. You open the diagram, let the parallel loading finish, and use Fit to get the overview. You search for a known table by name, isolate it, and study its incoming and outgoing relationships. A click on a connected table opens its own detailed view in the Browser, without losing the state of the diagram.

For MongoDB or legacy schemas, opening the Virtual Relations panel lets you manually declare the implicit links. Once entered, they appear immediately in the diagram as purple dashed lines and become usable by QoreDB's other views, such as the Foreign Key Peek or the Browser.

A daily analysis tool

QoreDB's ER diagram is deliberately a faithful view of the catalog, not an autonomous reverse-engineering process. It shows the relationships the database knows about, plus those the user has explicitly declared, and nothing else. This choice makes it readable, predictable, and suited to daily use on real schemas. For a developer arriving at an existing database, it's often the first entry point before writing a single query.

Newsletter

Stay updated on new releases

Subscribe to get product releases, new drivers notifications, and technical tutorials.

🎁 Bonus: Get our free SQL Performance Cheat Sheet — 9 pages, PostgreSQL / MySQL / SQLite (PDF)!
Share