Design Model Overview

DbSchema maintains its own design model — a local copy of your schema stored as an XML .dbs file. This model is completely independent of any database, which means you can open, edit, and share it without a live connection.

What the Design Model Is

• Format: XML, human-readable, openable in any text editor.
• Database-independent: the same model can be deployed to MySQL, PostgreSQL, SQL Server, and other RDBMS.
• Persistent: contains your schema structure, diagrams, virtual foreign keys, and comments. Everything is preserved between sessions.

Online vs Offline Mode

DbSchema can work in two modes:

• Online (connected): every schema change you make is immediately applied to the database. Executed statements are listed in the SQL History pane on the left.
• Offline (disconnected): changes are saved only to the design model file. No statements are sent to the database.

Switch between modes at any time from the connection menu — choose Disconnected to go offline and continue designing without a database.

Working Offline Then Reconnecting

A common workflow is to design offline, then reconnect when you are ready to apply changes:

1. Make schema changes while disconnected — they are saved to the .dbs file.
2. Reconnect to the database.
3. Click Refresh Model from Database to detect differences.
4. Review each difference in the Synchronization Dialog and choose to apply it to the database, update the model, or generate a migration script.

Converting the Schema to a Different RDBMS

You can retarget an existing model to a different database engine:

1. Open Model → Model Properties.
2. Select the new database from the RDBMS field.
3. DbSchema shows a preview of how each data type will be converted.
4. Confirm and save the model to a new file.

Triggers, functions, and stored procedures cannot be converted automatically and must be rewritten manually.

Sharing the Model via Git

Because the .dbs file is plain XML, it works naturally with any version control system — Git, Mercurial, SVN, and others. Team members can each work on a local copy, commit their changes, and merge them like any other source file.

You can also open two .dbs files simultaneously and synchronize between them — useful for comparing schema versions or generating migration scripts between branches.

Export the Differences as a Change Report

Every comparison opens the Synchronization Dialog, whether it compares the model with the database, with a Git commit, or with another model through Model → Compare Model with Other Model From File. The Export Report button in its toolbar writes the differences as a document, to keep with a release or to share with people who do not use DbSchema.

• Changes sets the direction of the report. It reads from the file, the database or the Git reference to the model by default, so for two releases with the new one open, it lists what the new release added, removed and changed.
• Include chooses which differences go in: only those that the filter of the Synchronization Dialog shows, the ones marked as ignored, and, as an appendix, the SQL script that turns the first side into the second. A logical design has no SQL script.
• Format is HTML or Markdown. The HTML page carries its own styles, so it survives an email attachment or a wiki upload, and the browser's Print to PDF turns it into a complete PDF. Markdown suits a Git repository, a pull request or a wiki.

The report opens with a summary: how many tables, columns, indexes and foreign keys each side holds, and the number added, removed and changed for each kind of object. The changes follow, grouped by schema and by table, one line per change with the value before and after, so a column whose data type changed shows the old type beside the new one. In the HTML page, buttons above the list show only the added, removed or changed objects.