Your whole stack in one client

Where this fits

Be clear about the ordering. The reason to buy SQL DATA LENS is what it does with InterSystems IRIS and Caché: globals, namespaces, cached queries, class storage. Nothing on this page competes with that.

What this page is about is the other half of your week. The extract that arrives as a CSV. The SQL Server instance the interface writes to. The Parquet file from the data platform team. Handling those in the same window means you are not paying for and learning a second client to do work that is adjacent to the work you already do here.

What it connects to

Native, drivers included

8 InterSystems drivers ship inside the app — 7 IRIS versions from 3.3 to 3.10.5 plus Caché 2018.1 — loaded side by side in isolated classloaders.

• InterSystems IRIS
• InterSystems Caché

Over JDBC

You supply the driver JAR for anything commercial; the open-source ones are already there. Connections are configured once and grouped in the same tree as your IRIS servers.

• Microsoft SQL Server
• PostgreSQL
• MariaDB / MySQL
• DuckDB
• SQLite
• H2
• Trino
• Apache Derby
• Microsoft Access
• Microsoft Excel

Files, queried as tables

No import step, no staging table, no schema to define first. The file is the table.

• CSV (single file, folder or ZIP)
• Parquet
• JSON

DuckDB: an analysis engine that is already there

A colleague sends you a 2 GB Parquet extract and asks whether it is the right one. Before you load anything into anything, you want three facts: what columns it has, what the values look like, and how many rows there are.

SQL DATA LENS has built-in DuckDB connections that run in memory. There is no server to install, no database file to create and no driver to download — you open a DuckDB connection and it exists. Drag a CSV, Parquet or JSON file onto that connection and the editor fills with the statements to inspect it: a SELECT that runs straight away, plus a DESCRIBE for the column names and inferred types and a SUMMARIZE for per-column row counts, null counts, distinct counts, minimum, maximum and averages. Those last two arrive commented out — uncomment the line and run it. Nothing profiles two gigabytes behind your back.

That is the whole question answered in a few seconds, without importing the file, without writing a loader, and without a copy of the extract landing in a database where it will be forgotten. When you do want to keep the results, the grid exports the same way every other result grid in the app does.

CSV text connections: a folder of files as a schema

The second route to a file is a CSV text connection, which treats plain text files as SQL tables directly. Two shapes are useful in practice:

• A ZIP archive. Pick the archive and each CSV inside it becomes a table — the usual shape of an official statistics download or an export someone has mailed you.
• A folder. Point the connection at a directory and every *.csv in it is queryable, named after the file. A folder containing population.csv gives you:

  SELECT * FROM population LIMIT 100

Nothing is imported and nothing is converted. The files stay where they are, and when the next month's export overwrites them your queries still work.

The real payoff: one statement, two systems

Separate connections in separate tabs is convenience. Joining across them is the thing that actually saves an afternoon. Because everything above is a connection like any other, a single statement can join an IRIS table against a SQL Server table, or against the CSV file the reconciliation was delivered in — combined on the client, with nothing installed on any server.

That is Query Cloud, and it is where the generic-database support stops being a checkbox. "Which of the 4,000 IDs in this spreadsheet are missing from the production namespace?" becomes one query instead of an export, an import and a temporary table.

Everything else you expect from the app applies to these connections too: the same Table Viewer for browsing and filtering, the same editor, the same export formats. The IRIS-specific views are naturally absent — a PostgreSQL database has no globals to browse.

When a generic tool is the better answer

If your team runs thirty database systems and IRIS is a footnote among them, a generic client is the right choice, and DBeaver or DataGrip will serve you better than this will. They cover more engines, they have deeper support for each engine's own dialect and administration, and they run on macOS and Linux today.

SQL DATA LENS is built the other way round: IRIS and Caché in depth, with enough breadth that a second tool is usually unnecessary. If IRIS is where your difficult questions live, that trade is worth making. If it is not, it is not.

The honest comparison with DBeaver, DataGrip and the Management Portal →

Next step

The fastest way to judge this is to open a DuckDB connection and drop your most annoying file onto it. That path needs no licence and no server.

See which editions cover which databases →