Why I Built a Schema Documentation Generator

New developer joins the team. Day one.

"Where can I find the database schema docs?"

You know what happens next. You point them at SSMS. "Just... look at the tables." They spend two days figuring out what TblOrdDtl means, which columns are nullable, and why there seem to be three tables that store the same customer data.

I've been that new developer. I've also been the one saying "just look at the tables." Across every enterprise project I've worked on, every single team had the same answer to "where are the database docs?": nowhere.

It's not that nobody cares

Everyone agrees the database should be documented. Nobody does it. Not because they're lazy — because the process is awful.

Open SSMS. Click on a table. Write down every column name, type, size, nullability, constraints. Move to the next table. Repeat for 30 tables. By table 10, your eyes are glazing over. By table 20, you're making mistakes. By table 30, you need a break. And the moment the schema changes next sprint — which it will — your documentation is already stale.

Documentation that can't keep up with changes is worse than no documentation. It gives false confidence. Someone reads the docs, makes an assumption about a column type, and ships code based on a doc that was accurate two weeks ago.

2 seconds

SchemaDocGenerator.exe ecommerce.sql

Export your schema from SSMS (Database > Tasks > Generate Scripts > Schema Only). Point the tool at the file. Get a complete Markdown document in 2 seconds.

The output includes: a summary (table count, column count, generation timestamp), a table of contents with links, and a detailed section for each table — every column with its type, size, nullability, and constraints (PRIMARY KEY, UNIQUE, IDENTITY, NOT NULL).

It's Markdown, so it goes anywhere. Push it to GitHub. Paste it in Notion. Open it in VS Code. Convert to PDF. When the schema changes, re-export, re-run. Your docs match reality again.

A different kind of product

The first three products generated code. This one generates documentation. It felt like a shift — from "automate what developers write" to "automate what developers should write but never do."

I call it the "Document" layer. After you generate your code (Products #1, #2, #3), you document your schema (#4). Later, Product #5 and #6 would add validation and migration. But at this point, the toolkit idea wasn't fully formed yet. I was just solving the next problem that annoyed me.

That's how all six products happened, actually. Not from a grand plan. From a list of things I was tired of doing manually.

Available on Gumroad for EUR 10.