Jaco van der Laan

Expertise · Modeling tools

Your IDE is the modeling tool.

Traditional modeling tools export SQL once, and your edits to that SQL never flow back — a broken loop. I build the other way: the model lives as code in your IDE and Git, and SQL, diagrams, docs and dbt are generated from it. The loop closes.

The model as code in VS Code and Git generating SQL, ERDs, docs, tests, dbt and lineage
Model as code; generate SQL, diagrams, docs, tests and dbt. The loop PowerDesigner never closed.

The ideas behind it

What makes my approach different.

The IDE as the modeling tool

What if VS Code was your modeling environment? Model as YAML, edit visually or as code, version in Git — and keep model and SQL in sync both ways. No more GUI-only tools where the SQL export is a dead end.

Extend the tool you have, do not replace it

At de Volksbank I extended PowerDesigner with custom extensions until it drove model-based generation. The lesson stuck: a standard tool, extended with structure, beats adopting a whole new platform.

Model merges should not be a nightmare

Merging models in PowerDesigner or ERwin is fragile GUI pain. Model-as-code makes a merge a normal Git merge — reviewable, diffable, continuous metadata integration instead of manual reconciliation.

One core, many runtimes

A shared abstract core (the SQL and model AST) with thin per-engine adapters — Databricks, Snowflake, Fabric, Spark. Build the logic once; let each platform get its own optimized output.

From the writing

I build the tools I wish existed.

Read the archive →

Fighting your modeling tool instead of using it?

I build modeling tooling that fits how teams actually work — model as code, generate the rest.

Start a conversation