What is a data dictionary?

A data dictionary is reference documentation describing each field in a database — its name, type, constraints, and meaning. It helps engineers and analysts use a schema correctly without reverse-engineering the code.

What does the nullable column mean?

Nullable indicates whether a column may store a NULL value. Marking it accurately is important because it affects queries, validation, and how application code must handle missing data.

What output format does it produce?

It generates a GitHub-flavoured Markdown table with one row per field, which renders cleanly in READMEs, wikis, and most documentation tools. You can paste it directly without reformatting.

Should I include validation rules?

Yes. Capturing rules like a max length, a regex, or an allowed-value set documents constraints the database type alone does not express, which prevents bad data and clarifies intent for other developers.

Is my schema sent to a server?

No. The builder runs entirely in your browser, so table and field names stay on your device. Copy the Markdown output to save it wherever you keep your docs.

What is the Data Dictionary Builder?

Builds a database data dictionary with field name, data type, nullable flag, default value, description, and validation rules per column — rendered as a clean Markdown table you can copy into docs. It runs free in your browser on Gera Tools, with nothing uploaded.

Data Dictionary Builder

Name: Data Dictionary Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Schema documentation that stays in sync with intent

A data dictionary tells everyone what each column means, what it can hold, and what rules govern it. This builder turns a list of fields into a clean Markdown table — name, type, nullability, default, description, and validation — ready to drop into a README or wiki.

How it works

You name the table, then document each field with its data type, whether it is nullable, a default value, a plain-language description, and any validation rules. The tool escapes pipe characters in your text so they do not break the table, then renders a GitHub-flavoured Markdown table with one row per field and a header row. Nullability is shown as a clear Yes or No. Because the output is standard Markdown, it renders correctly in GitHub, GitLab, Notion, and most documentation systems without any reformatting.

Tips and example

Use canonical type names from your database — VARCHAR(255), BIGINT, TIMESTAMPTZ — so the dictionary matches the real schema.
Write descriptions for a newcomer: explain the business meaning, not just the type.
Capture validation the type cannot express, like must match email regex or 0 < amount <= 10000.
Keep one dictionary per table so each stays focused and easy to review in a pull request.

Why a data dictionary is worth maintaining

Without a data dictionary, the meaning of columns lives only in the head of the engineer who created them or in the application code. This creates predictable problems: analysts write wrong queries because they misread a column’s purpose; new engineers make assumptions about nullable columns and introduce bugs; product managers cannot understand what is actually stored; and compliance reviews take far longer because no-one has documented what personal data lives in which field.

A data dictionary solves this by making the schema legible to everyone who works with the data — not just those who built it.

What to document for each field

Column	What to write
Name	Exact column name as in the database
Type	Database type including length/precision: `VARCHAR(255)`, `DECIMAL(10,2)`, `TIMESTAMPTZ`
Nullable	Yes or No — a binary answer; do not leave it blank
Default	The actual default value, or “none” if there is no default
Description	What the field means in business terms, not just its technical type
Validation	Any rule the type cannot express: regex patterns, value ranges, foreign-key relationships, enum values

The most commonly under-documented column is validation. A column typed INTEGER NOT NULL tells you nothing about whether 0 is a valid value, what the maximum is, or whether it represents a foreign key to another table. Capturing those rules prevents silent data quality failures.

From Markdown table to documentation system

The Markdown output this builder produces renders natively in GitHub and GitLab READMEs, Notion pages, Confluence (via the Markdown import), and most wiki systems. A practical workflow is to include a SCHEMA.md or DATA_DICTIONARY.md file alongside your migration files, updated whenever the schema changes. In a code review, a diff to that file makes schema changes immediately legible to reviewers without them having to read raw SQL or Prisma migration files.

For larger organisations, the same content can be imported into a data catalog (Amundsen, DataHub, Alation) that makes it searchable and linkable across the whole data estate.