39 posts tagged with "dbdocs"

Students and teachers use dbdiagram to learn databases. We see it in coursework diagrams, in lecture material, and in the emails asking us whether there is a student discount.

Today we're happy to announce the Education Program: students, teachers and researchers get Pro licenses for free.

What's new:

• Personal Pro, free for one year, renewable while you are still at an institution. Unlimited diagrams and doc projects, private sharing, and the visualization tools for large databases, on one workspace you pick. Apply again when the year ends.
• Apply with your school account. Your name, your role and your institution. No scanned ID and no enrollment letter.
• Recognised school domains are approved automatically, usually within the hour. A domain we do not recognise is reviewed, usually within a few working days.

Note: Open to students, teachers and researchers applying on a school or university email address. Personal addresses such as Gmail and Outlook are not eligible, so sign in on your institution account before you apply.

📚 Apply now →

We hope dbdiagram makes databases easier to learn, and easier to teach.

We're happy to announce three changes to our pricing: one plan covers dbdiagram and dbdocs, private mode is now free, and the dbdocs paid-project add-on is gone.

Use one plan for both products, and keep a schema private without paying for it.

We got some of this wrong. Charging for privacy meant that to try dbdiagram, you had to publish a production schema to the internet. Charging per private project meant a counter you had to keep in sync with your subscription by hand. What you pay for now is working on a schema with the people you invite.

What's new:

• One plan covers dbdiagram and dbdocs. Personal Pro is $96/year for both, against $96 plus $192 for the two plans bought separately.
• Private by default on Free. New diagrams and doc projects start private, on both products. Publish a view-only link when you want to share one.
• The dbdocs paid-project add-on is gone. You no longer buy private projects one at a time.

📚 See the plans →

Note: Existing subscriptions are not changed. If you are on a legacy plan or still hold the dbdocs paid-project add-on, cancel and resubscribe at the end of your term to move to the new pricing, or email us to switch over straight away.

We're also working on free licences for students and teachers. More on that soon.

Fewer people are drawing database diagrams than a year ago. Between agents doing more of the work and a tighter economy, this is a hard stretch for tools like ours. Thank you for staying with us. We will keep improving our products.

We'd love to hear your feedback.

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.