dbt schema.yml Generator
Paste a CREATE TABLE statement or a list of column names and get a ready-to-commit dbt schema.yml: column descriptions, data types, and not_null, unique, relationships and accepted_values tests inferred from the DDL. Optionally generate a dbt unit test skeleton too. Everything runs in your browser.
Detected 8 columns, primary key: order_id.
- Relationships tests were generated by guessing the referenced model from the *_id column name. Check each ref() points at a model that actually exists.
- accepted_values lists are placeholders. Replace them with the real domain values before committing, otherwise the test will fail on your first run.
Parsing and YAML generation run entirely in your browser. No DDL is sent to a server. Generated tests are a starting point — review the ref() targets and accepted_values lists before committing.
Do more than dbt schema.yml generator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Paste a CREATE TABLE statement, or type one column name per line, and set the dbt model name.
- Choose which tests to infer and whether to use the modern data_tests key or the legacy tests key.
- Copy the YAML into models/<folder>/schema.yml, then replace the placeholder descriptions and accepted_values.
Frequently asked questions
Should I use tests: or data_tests: in schema.yml?
dbt 1.8 renamed the property from tests to data_tests so that data tests and unit tests have clearly separate keys. The old tests key still works and is not scheduled for removal in 1.x, but every new project should write data_tests. If your project runs on dbt 1.7 or older, switch this generator to the legacy tests key — data_tests is not recognised there and dbt will warn that the property is unexpected.
What is the difference between a dbt data test and a unit test?
A data test runs against the rows actually in your warehouse: not_null, unique, relationships and accepted_values are all data tests, and they fail when real data violates an assumption. A unit test, added in dbt 1.8, runs your model's SQL against fixed input rows you supply in YAML and compares the output to an expected result, so it catches logic regressions without needing production data and runs in seconds. Use data tests to monitor incoming data quality and unit tests to pin down transformation logic — especially tricky CASE expressions, window functions and date maths.
How does this tool infer which tests to add?
Columns marked NOT NULL or PRIMARY KEY in the DDL get a not_null test, and primary keys also get a unique test so your model grain is enforced. Columns ending in _id that are not the primary key get a relationships test pointing at a guessed model name, and columns named like status, state, type or category — plus boolean columns and is_/has_ flags — get an accepted_values test with placeholder values. These are starting points, not finished tests: always review the ref() targets and replace the placeholder value lists. If you want to explore the real distinct values in a column before filling them in, Chat2DB (https://app.chat2db.ai) lets you query the source table and read the results without leaving the browser.
