What changed
JetBrains DataGrip 2026.3 introduced a per-project Workspace data source backed by in-memory DuckDB. It runs SQL across existing database connections, including different DBMSs, and returns joined results directly in the IDE. The release also adds first-class DuckDB syntax and connection support.
Why it matters
Builders who need to compare production-adjacent datasets across PostgreSQL, MySQL or other sources can perform exploratory joins without standing up Trino, copying tables to an intermediate server or writing one-off export scripts. This reduces setup friction, not the need to control credentials, data movement and query costs.
How the Workspace works
Each DataGrip project can create one Workspace data source and multiple query consoles. A special qualified table-reference syntax selects tables from existing data-source connections; embedded DuckDB executes the cross-source query. The Workspace is in memory by default and does not require a persistent DuckDB file.
Why DuckDB was selected
JetBrains considered Apache Calcite and internal query handling before selecting DuckDB custom table functions. The team says they allowed it to reuse existing query execution and obtain some optimisation capabilities without building a query engine. This is a vendor/implementer account, not an independent benchmark.
Operational boundaries
The feature uses DuckDB SQL dialect, which may differ from the SQL supported by connected systems. Cross-source reads can move data between sources and the local IDE process; teams should check permissions, network transfer, memory limits, sensitive data handling and query plans before treating this as a production data pipeline.
First release, not a federated database replacement
JetBrains calls this an initial solution. Further optimiser integration and file-based data sources are prospective rather than shipped capabilities. No independent performance or large-dataset reliability benchmarks were established.