37 posts tagged with "dbdocs"

We're happy to announce that DBML now supports custom properties: you can add key-value pairs to your tables and columns.

Use them to record who owns a table, which fields hold personal data, or anything else your team tracks.

Write them inline in the settings list, or in a separate Metadata block:

Table users [owner: "identity-team", pii: "true"] {
  id int [pk]
  email varchar [classification: "confidential"]
}

// or keep the properties apart from the schema
Metadata Column users.email {
  masking: 'partial'
}

What's new:

• Any key you need, on tables, columns and table groups: owner, classification, retention, SLA, etc.
• Properties live in your DBML, so git versions them with the schema and your own scripts can read them.
• Filter tables and fields by key and value in dbdiagram and dbdocs, matching the whole value or just part of it.
• Read them in place: properties show up in the diagram view and in your dbdocs database doc, so whoever is reading the schema sees them without opening another tool.

Note: Custom properties and the property filter are available on all plans.

📚 Learn more →

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

We're excited to announce that dbdiagram and DBML now support visualizing data lineage: how your data moves and transforms across tables.

You define dependencies with the new Dep syntax:

// one line per step
Dep: stripe_payments -> daily_orders [note: 'Cleaning: drops voided charges']

// or map the columns, and pull several tables into one
Dep monthly_revenue_build {
  daily_orders.amount -> monthly_revenue.revenue
  daily_orders.ordered_at -> monthly_revenue.month
  refunds.amount -> monthly_revenue.refunds

  note: 'Aggregation: orders by month, minus refunds.'
}

Why it matters:

• Design before you build. One line per step is enough to sketch a whole pipeline in plain text, and get review on its shape before any SQL exists.
• Answer "where does this number come from". Map single columns, then click one in the diagram and every table it travelled through lights up.
• Schema and flow on one canvas. Ref and Dep draw as different edge styles, so you can show them together or separately, whichever the diagram needs.
• Notes explain what each step does. Add a note to any dependency to describe the step in plain words, so the meaning sits beside the arrow instead of in a separate doc.

Reading lineage straight from a dbt project or your warehouse is what we are working on next.

Note: Data lineage is available on all plans, with no limit on project size.

📚 Read the full syntax docs →

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

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.