Managing Database Schemas as Code with DataGrip Projects

Binding a Database Project to a data source

Creating a Database Project in DataGrip is the first step toward schema-as-code. From the welcome screen or the file menu, you choose New Database Project and are prompted to add an existing data source connection. The IDE then binds that connection to a folder on disk. Unlike proprietary formats, the project folder contains plain SQL scripts, one per migration or schema state, so they can be opened in any editor, tracked in Git, or shared across teams. Once bound, DataGrip begins monitoring the schema state of the connected data source, using it as a reference point for subsequent diff and generation operations. The project can be linked to multiple data sources, letting you compare the same migration scripts against dev, test, or production databases without reconfiguring the folder.

Visual diff and migration generation

Within a project, DataGrip can compare the current database schema against the project files or against another data source. The comparison opens a visual diff panel that categorizes changes into added, removed, and modified elements tables, columns, indexes, constraints, and even default values. Each change is highlighted with a description of what was altered and where applicable the original and new values. From this panel, you can invoke Generate Migration which creates a new SQL file in the project folder representing the proposed changes. The generated SQL is dialect-aware: DataGrip formats the statements according to the target database engine's syntax for example PostgreSQL SERIAL SQL Server IDENTITY MySQL AUTO_INCREMENT. Before saving, the IDE shows a preview of the generated SQL in the editor, letting you review and tweak the script before it becomes part of the project's version history.

Applying changes with version control and safety

When a migration file is ready to be applied, DataGrip provides an Apply action that executes the SQL against the selected data source. The interface always requires a preview step before execution a deliberate safety gate. Skipping the preview can result in unintended DDL being run, potentially causing data loss, especially on databases with active workloads. For this reason, the recommended workflow is to apply migrations against a read-only or snapshot data source during preview, confirm the expected state, and only proceed to a writable source after validation. Once confirmed, the migration file can be committed to a Git repository alongside application code. This gives the team a full history of schema changes, the ability to roll back by reverting to a prior migration, and reproducible provisioning across environments. The IDE also supports rolling back a migration by generating a reverse script, though the success of a rollback depends on the database engine's capabilities and the nature of the change.

Verification checklist

• Open DataGrip and create a new Database Project from the welcome screen.
• Add an existing data source connection using your preferred credentials.
• Use the context menu on a schema object (or the project comparison tool) to run Compare with Project and inspect the visual diff panel for added, removed, and changed elements.
• Generate a migration from the diff and review the proposed SQL in the editor before using the Apply action to confirm preview behavior.
• Commit the project folder to a local Git repository and verify that the schema files are tracked and can be opened on another machine with the same data source configuration.

Trade-offs and limitations

While DataGrip's Database Projects provide a strong schema-as-code workflow, there are practical trade-offs to consider. Dialect support for diff generation and migration syntax varies by database engine; generated SQL may require manual review for edge cases such as custom types, stored procedures, or partitioned tables. Large schemas can make diff and apply operations slow and memory intensive, so scoping projects to incremental domains, such as a single application's database, is recommended. Additionally, menu locations and feature wording are version-sensitive, shifting between major DataGrip releases, so the UI steps described here may differ if you're on an older or newer version. Finally, the Apply action is destructive by design; it executes DDL directly against the target data source, so production use always requires read-only preview, explicit safety checks, and ideally a backup or point-in-time recovery plan.