This Add-on allows you to open a DataGrip instance and connect to your local DDEV database without any manual configuration. It can also automatically use the MariaDB driver if it detects MariaDB instead of MySQL running in DDEV. As of 2025.2.5a, this Add-On now supports Postgres!
ddev add-on get natereprogle/ddev-datagrip
ddev restart
After installation, make sure to commit the .ddev directory to version control.
Note
DDEV doesn’t support changing its DB credentials, so it should be well known that its default credentials are db:db. To configure DataGrip correctly, this Add-On will store these credentials in the .ddev/datagrip folder in your project. If you use tooling such as Gitleaks, be sure to configure it to prevent false positives.
| Argument | Description |
|———-|————-|
| --database [database] | Specify the database to connect to |
| --reset | Resets the DataGrip project, including configuration and generated schemas. A manual refresh will be required upon next launch of DataGrip |
| --auto-refresh [time in minutes] | Enables auto-refresh in DataGrip. This only works if the datasource has been refreshed at least once. Minimum of 0.1 minutes (6 seconds), set to 0 to disable. Default is 1 minute |
| --pg-pass | Only applicable for DDEV projects using Postgres. This will utilize pgpass (~/.pgpass) instead of User & Password for connecting to the Postgres database. It is required to provide this argument each time you want to authenticate with pgpass. Omitting this will default back to User & Password |
| --help | Get command help |
Connect to your local default DDEV database
ddev datagrip
Connect to your local DDEV database using a specific database name
ddev datagrip --database my-db
Reset your datagrip configuration and datasource (note this will require you to manually refresh the datasource onced datagrip is launched)
ddev datagrip --reset
Set the auto-refresh delay to 30 seconds instead of 1 minute
ddev datagrip --auto-refresh 0.5
Use pgpass when connecting to a Postgres DB
ddev datagrip --pg-pass
JetBrains reserves the right to change how DataGrip is configured at any time, and this configuration may or may not be backwards compatible with older versions. Therefore, this Add-On will only ever be developed & tested on the latest version of DataGrip (including EAP versions). Personally, I have tested this Add-On with DataGrip 2025.2.5 and later – including 2026.1 – with success.
The version of this Add-On will reflect the minimum version of DataGrip this Add-On supports. Meaning, if you see the add-on is on version 2025.2.5, that means the Add-On is tested and confirmed to support all DataGrip versions 2025.2.5 and later.
A letter or extra decimal may be appended to the version when necessary to publish an update. For example, 2025.2.5a or 2025.2.5.1 both target a minimum version of 2025.2.5. Anything after the date can be safely ignored in terms of compatibility.
Note
An exception to this is EAP versions of DataGrip. If the Add-On version ends with EAP (case-insensitive), this indicates that the applicable version of the Add-On only supports a minimum of that EAP version of DataGrip.
For example 2025.2.5eap, 2025.2.5EAP, and 2025.2.5.1EAP all require DataGrip version 2025.2.5 EAP (If such a version existed, which it does not). 2025.2.5EAP.1, 2025.2.5EAPa, and 2025.2.5EAP123 do not require the EAP version as they do not end with EAP.
Unlike other SQL tools like Sequel Ace, SQL Pro, and others which can be launched with CLI arguments to immediately connect to a Database, DataGrip requires a “Project”. A Project is a directory which contains several configuration files, including ./.idea/dataSources.xml and the DB schema, located in ./.idea/dataSources/ and generated by DataGrip automatically. Projects must be created with the DataGrip GUI. When DataGrip connects to a Data Source, it does so by creating a “Session”. Sessions are created when various actions in DataGrip occur, such as (but not limited to) adding a Data Source to a Project. Sessions, among other things, also trigger Introspection.
In order to support DataGrip at all, this Add-On creates a Project and the necessary configuration files for you within the .ddev/datagrip directory. These files are based on a manual review of “real” datagrip configuration files and contain only the bare minimum configuration necessary to make DataGrip work with DDEV. However, because DataGrip was never intended to be configured this way, this skips several steps that DataGrip typically performs on its own, the most important of which being the initial introspection, schema generation, and caching. Because these steps aren’t executed, Automatic Introspection also will never trigger and subsequent launches of DataGrip will never generate schema or trigger introspection, either.
Unfortunately, this behavior is by design. Nothing in the documentation shows any method of automatically triggering a Session to be created. The only workaround for this issue is to do a manual refresh on the very first launch of DataGrip. After this is done, future usage of the ddev datagrip command will not require a refresh as DataGrip will load data from the Project cache instead. However, if the DB schema is changed, datagrip may require a manual refresh again. The Add-On attempts to mitigate this by configuring an automatic introspection interval of 1 minute, but again, this only runs after initial refresh. This is a limitation of DataGrip, not DDEV or this add-on. We hope this can be improved in the future, but as of DataGrip 2026.1, it is not an option.
DDEV uses db:db as its DB credentials. As it’s meant for local development, they’ve also stated they have no plans to allow changing this. This add-on stores DDEV’s DB credentials in plaintext in the JDBC URL within dataSources.xml. Certain tools, like Gitleaks, may pick up on these credentials and throw a fit. You will need to make adjustments to your tooling if storing these credentials in plaintext is an issue.
The only exception to this is if you use pgpass for authentication when using a Postgres database. However, tooling may still pick up on the credentials hardcoded in the Add-On itself, and this is not something that can be resolved.
ddev datagrip while DataGrip is runningSometimes, when ddev datagrip is run while DataGrip is already open, certain configuration values will not reflect their “true” value until DataGrip is restarted. An example of this can be found if you are using Postgres and typically use ddev datagrip --pg-pass to utilize .pgpass when authenticating. If you decide to execute ddev datagrip instead, which will use User & Password authentication, the Data Sources panel will show pgpass as the Authentication method but DataGrip will still use User & Password instead to authenticate. A restart of DataGrip is required to show the correct datasource properties.
It is recommended that you exit DataGrip fully before running ddev datagrip to prevent any issues or quirks.