Following foreign keys in DBeaver, pgAdmin or IntelliJ: one row at a time

You know the drill. Something looks wrong for one company in the database, and to understand what's going on you need to see everything connected to it: its departments, the teams in each department, the employees in each team, their managers.

I'm not doing this in raw SQL. I use the same tools as most of us: DBeaver, pgAdmin, or the Database tool in IntelliJ. They're great tools. But for this specific job, they all work the same way, and it gets painful fast.

What it looks like today

You open the companies table and find the row. Then you open departments in another tab and filter on company_id. Then teams, filtered on the department you care about. Then employees. After five minutes, your screen looks like this:

Four tabs, four manual filters, and the relationships between them only exist in your head.

The real problem: you only see one direction, one row at a time

Most clients let you click a foreign key value and jump to the row it points to. That's useful, but it only goes one way and one row at a time:

• From a child, you can reach its parent. From a team, you jump to its department.
• From a parent, you don't see its children. If a department has 3 teams, nothing on the department row tells you that. You have to know the teams table exists, open it, and filter on department_id yourself.
• Going deeper multiplies the work. Each team has employees, each employee has a manager... Every level is another tab and another filter.

The data model is a tree (or a graph), but the tools show it as a pile of flat tables.

What I wanted instead

Pick a record, and expand it like a folder in a file explorer:

• its parents (the rows it references)
• its children (the rows that reference it), all of them, at once
• and the same thing again on any of those, as deep as I need

I couldn't find a tool that did exactly that, so I built one: DbTree. Same data as the screenshot above, as a tree:

It reads the foreign key constraints of your PostgreSQL database and only queries a level when you expand it, so it stays fast on large tables. The connection is read-only.

To be upfront about the limits: it's Windows-only and PostgreSQL-only for now, it relies on declared foreign keys (no guessing), and it's free up to 2 levels deep, with a one-time license beyond that.

Your turn

How do you explore related records day to day? Do you live with the tabs, write the JOINs, or have a trick I'm missing? I'd genuinely like to know.