Early Access Program News

DataGrip 2021.3 EAP Is Open

Hello! We have begun our DataGrip 2021.3 EAP and there is something really exciting inside.

Data editor


We’ve added the ability to display an Aggregate view for a range of cells. This is a long-awaited feature that will help you manage your data and that will spare you from having to write additional queries! This brings our data editor step closer to Excel and Google Spreadsheets! 

Select the cell range you want to see the view for, then right click and select Show Aggregate View.

Quick facts:

  • It shares the panel with Value view: now you have two tabs there. This panel can be moved to the bottom of the data editor.
  • You can use the gear icon to display or hide any aggregate from this view.
  • Like extractors, aggregates are scripts. You can create and share your own in addition to the nine scripts we’ve bundled by default.
  • Moreover, aggregate scripts and extractors are interchangeable. If you’ve previously used an extractor to get just one value, you can now copy it to the Aggregates folder and use it for aggregates.

One aggregate value is displayed in the status bar, and you can choose which value you’d like it to be.

Independent split

If you split the editor and open the same table, the data editors will now be completely independent. You can set different filtering and ordering options for them. Previously, filtering and ordering were synchronized, which obviously was useless.

Custom font

You can choose the dedicated font for looking at data under Database | Data views | Use a custom font.

Setting for default sorting

You can define which sorting method will be used as the default for tables: via ORDER BY or client-side (which doesn’t run any new queries and sorts only the current page). The setting can be found under Database | Data views | Sorting | Sort via ORDER BY.

Display mode for binary data

16-byte data is now displayed as UUID by default. You can also customize how binary data is displayed in the column.

[MongoDB] Completion for filter {} and sort {}

Code completion now works when filtering data in MongoDB collections.

Database in the Version Control System


This release is a logical continuation of the previous one, which introduced the ability to generate a DDL data source based on a real one. Now, this workflow is fully supported. You can:

  • Generate a DDL data source from a real one
  • Use the DDL data source to map the real one
  • Compare and synchronize them in both directions

Just as a reminder, a DDL data source is a virtual data source whose schema is based on a bunch of sql scripts. Storing these files in the Version Control System is a way to keep your database under the VCS. 

Database in the VCS: step-by-step workflow

Let’s take a look at the whole process. Imagine two developers, Alice and Bob, want their data source schemas to be synchronized via GitHub.

We advise users to store the project root folder in the VCS. Alice and Bob will sync their projects, which contain the DDL data sources for the sakila database. They both have their local data sources, but they want to synchronize them via VCS.

Alice enables version control integration on a project root folder, which is usually automatically displayed in the Files tool window.

She then creates a sakila_repo folder, which she’ll use as a schema representation to be synced via VCS.

First, Alice needs to create the DDL data source with help of the Dump to DDL data source action. This will be a file-based schema mirror of the real data source. It’s name is Sakila Alice DDL.

When creating a DDL data source, it’s necessary to specify that the files will be placed in the sakila_repo folder. 

DataGrip asks whether Alice wants to add new files to Git, and indeed she does.

Now the project, along with the sakila_repo folder, can be committed and pushed to the GitHub repo. Alice hasn’t defined the remote repo yet. This can either be done in advance or when the project is pushed.


Bob clones the project from GitHub, and now he has the same local connection and DDL data source, which can be synced via VCS. All he needs to do is map his local data source using the DDL one. This should be done in the DDL mapping tab of the data source properties.

Now, the DDL data source represents the repository version, and the local data source is still local. Thus, to synchronize them, Bob needs to go to the context menu of the data source and select DDL data source | Apply from postgres@localhost (DDL)

The migration dialog opens, and Bob needs to click Apply Right to Left. Viola! The data sources are synced.

Soon this migration dialog will be completely reworked, so in the stable release there will be a more convenient and powerful way to migrate from one data source to another.

File-related actions

All actions for files are available on DDL data source elements as well. For example, you can delete, copy, or commit files related to the schema elements just from the database explorer.


If this option is turned on, the DDL data source will be automatically refreshed with changes to the corresponding files. This was already the default behavior, but now you have the option to disable it.

Initial search path

In this UI you can define names for your database and schemas, which will be displayed in the DDL data source. DDL scripts don’t usually contain names, and in these cases there will be dummy names for databases and schemas by default.


Accidental spaces warning

If any value except User or Password has leading or trailing spaces, DataGrip will warn you about them when you click Test Connection.

[Oracle, SQL Server] Kerberos authentication

It’s now possible to use Kerberos authentication in Oracle and SQL Server.

[Oracle, DB2] Enable DBMS_OUTPUT

This new option in the Options tab lets you enable DBMS_OUTPUT by default for new sessions.

More options button

We’ve introduced a More Options button for cases when something unusual has to be configured for the connection but there’s no need to clutter up the UI. These options currently include the ability to add Schema and Role fields for Snowflake connections and buttons for configuring SSH and SSL to increase their discoverability.

Expert options

The Advanced tab now includes an Expert Options list. In addition to a common option to turn on the JDBC introspector (please contact our support before using it), there are some database-specific options:

Oracle: Disable incremental introspection, Fetch LONG values, Introspect server objects.

SQL Server: Disable incremental introspection.

PostgreSQL (and similar) : Disable incremental introspection, Do not use xmin in queries to pgdatabase.

SQLite: Register REGEXP function.

MYSQL: Use SHOW/CREATE for source code.

Clickhouse: Automatically assign sessionid

Database explorer

Table view for tree nodes

Pressing F4 on any schema node allows you to see the table view of the node’s contents. For example, you can get a view of all tables:

Or a table’s columns:

All data viewer capabilities are available here: you can hide/show columns, export to many formats, and use text search. 

[Clickhouse] Distributed tables

Distributed tables are now placed under a dedicated node in the database explorer

Query Console

Timestamps in output hidden by default

In line with this request, timestamps are no longer shown for query output by default. If you want to return to the previous behavior, you can adjust the setting in Database | General | Show timestamp for query output.

[MongoDB] Code completion for database names

Database names are completed when using getSiblingDB, and collection names are completed when using getCollection.

Additionally, field names are completed and resolved if used from a collection that was defined through code completion.


‘First row is header’ auto-detection

Starting from this version, when you open or import a CSV file, DataGrip automatically detects that the first row is the header and contains the names of the columns.

image description

Discover more