35 posts tagged with "dbdocs"

Back in Zero-to-One/Many Relationships we started drawing optional relationships, working it out from the nullable constraint on the foreign key. Now you can say it directly: add a ? to either side of a relationship operator to mark that side optional. It works with all four operators (<, >, -, <>).

Table orders {
  id int [pk]
  customer_id int [ref: ?> customers.id] // a customer may have no orders
  coupon_id int [ref: ?>? coupons.id]    // an order may have no coupon
}

New to relationship types, or want to see optional refs across one-to-one, one-to-many and many-to-many with sample data? Read the tutorial on optional relationships.

📚 Read the full syntax docs →

Give it a try and let us know what you think.

You can now work with both dbdiagram and dbdocs from a single command line. The dbdiagram CLI syncs your local .dbml files with your diagrams and publishes documentation to dbdocs.io — from your terminal or CI pipeline, no app needed.

Keep your schema in version control, push it to update the diagram, and pull to bring web edits back into your repo.

What's new:

• Sync diagrams both ways with push and pull — schema and table positions included
• Publish docs to dbdocs.io with build document
• Set up once with init — later commands run without repeating flags
• Automate updates in CI with a DBDIAGRAM_TOKEN, no browser login needed

Example:

npm install -g dbdiagram
dbdiagram auth login
dbdiagram init --entry schema.dbml --diagram-id <id>

dbdiagram push    # local DBML → update the diagram
dbdiagram pull    # diagram → update local DBML

RunSQL support is coming next, so you'll design diagrams, publish docs, and test SQL queries from one CLI.

📚 Learn more →

Please give it a try and let us know what you think.

We're excited to introduce DiagramView-as-code — a new way to define diagram views directly in your DBML code, with no UI action needed.

Your view settings now live right alongside your schema in DBML. This means your views are version-controlled alongside your schema changes, making it easy to automate documentation and share consistent view configurations across your team.

What's new:

• Define a default view to persist your filter settings in code
• Create named views for stakeholders: DiagramView "Sales Team", DiagramView Engineering
• All diagram view filtering — work the same whether set via UI or DBML

Example:

DiagramView "Sales Team" {
  Tables {
    customers
    orders
    products
  }
  TableGroups { sales }
}

DiagramView Engineering {
  Tables {
    users
    sessions
    events
  }
  Schemas { core analytics }
}

Note: Named views (DiagramView <name>) are available on our paid plans. Free users can only filter tables within the default view (DiagramView Default).

📚 Learn more →

Please give this feature a try and let us know what you think.

Great news! We're introducing Data Sample — a feature that lets you add example data rows directly alongside your table definitions in DBML. Now your diagrams can show not just schema, but actual data, making them far more meaningful and useful for team communication.

Here's a simple DBML example:

Table plans {
  id int [pk]
  name varchar
  price decimal

  // define inside table definition with implicit column list
  Records {
    1, 'Free', 0
    2, 'Pro', 8
    3, 'Team', 15
  }
}

// OR define outside table definition
Records plans(id, name, price) {
  1, 'Free', 0
  2, 'Pro', 8
  3, 'Team', 15
}

Define sample data right in DBML, and your diagram instantly comes alive. You can import SQL INSERT INTO statements to auto-populate records, view them in the diagram with a single click, and export back to SQL for database seeding. This keeps your reference data and schema definitions in perfect sync across docs and deployment.

Why it matters:

• Your diagrams explain themselves — team members see actual data shapes and values, not just column definitions.
• Lookup tables finally have a home — define plans, roles, and other reference tables with their data, all in one place.
• Catch schema problems early — real data reveals missing columns, type mismatches, and broken relationships before migration.
• Convert existing data seamlessly — import SQL statements and auto-convert to Records for instant visualization.
• Seed your database faster — export sample data to SQL and deploy immediately.

Note: Data Sample is available on all plans.

📚 Read the full syntax docs →

Try it out and let us know what you think!

Great news! We've added support for Check constraints, allowing you to set rules on your table fields to enforce data quality—such as ensuring quantities are above zero or ratings stay within a range.

Here's a simple DBML example:

Table orders {
  id integer [pk, increment]
  price decimal [not null, check: `price > 0`]
  discount decimal [not null, default: 0, check: `discount >= 0`]

  checks {
    `discount < price` [name: 'valid_discount']
  }
}

Previously, these had to go in notes, which meant they could disappear during SQL imports or exports. Now, define them right in DBML, import and export with accuracy, and view them in your ER diagrams and docs for clearer sharing.

It's a simple way to make your databases more reliable and your documentation more informative. Update your diagrams now and start applying Check constraints!

📚 Read the full docs →

We hope these enhancements improve your database design and communication experience. Try them out and let us know what you think.