Security & privacy
What the tool does with your data: nothing
Runs entirely on your desktop, no telemetry, no admin rights required, signed binaries and a bundled private Java runtime.
- No telemetry, no analytics
- Two outbound connections in total
- Nothing installed on the server
- No administrator rights needed
- Bundled private JRE 21
The question behind the question
Most people reading this work on hospital information systems, insurance platforms, laboratory systems or banking back ends. Before a tool is allowed near that data, someone has to answer a short list of very specific questions, usually in writing, usually to a colleague who will not accept "enterprise-grade security" as an answer.
So this page lists what the application actually does, in terms you can verify with a firewall log and a directory listing. Where something is not supported yet, it says so.
Everything runs on your desktop
SQL DATA LENS is a Windows desktop application, not a client for a hosted service. There is no account to create, no sign-in, no workspace in the cloud and no server component of ours anywhere in the picture. Your queries run from your workstation against your database, over your network.
There is no telemetry and no usage analytics. Nothing counts which features you open, nothing samples your query text, and there is no crash-reporting service collecting stack traces in the background.
Every outbound connection, listed
Apart from the database connections you configure yourself, the application reaches exactly two destinations — our own update server and the LimeLM licence service — for the three purposes below. There is no fourth request and no fifth host:
| Purpose | When | What it carries | Optional |
|---|---|---|---|
| Update check | Free edition: at every application start. Pro editions: at most once every two days. | The installed version and edition, so the response can say whether a newer release exists. | Yes — it can be switched off in the settings, and the app runs normally without it. |
| Licence activation | When you activate or deactivate a licence key, and on the periodic re-validation that keeps an activation alive. | The licence key and a machine fingerprint, to the LimeLM activation service. | No. An activated licence re-validates periodically; without one, see the row below. |
| Trial verification | At every application start while no licence key is activated — during the 30-day Pro trial and afterwards, once the app has fallen back to the Free edition. | A machine fingerprint, to the same LimeLM service, so that the one-time trial cannot simply be restarted. | No. It stops once a licence key is activated, which replaces it with the row above. |
Both are straightforward to confirm from the outside: block outbound traffic from the workstation apart from your database ports and the app keeps working, minus the update notice. If your policy is to control updates centrally, turn the check off and roll out new builds the way you roll out everything else.
Nothing is installed on the database server
This is the point that usually settles the conversation with the platform team. SQL DATA LENS deploys nothing server-side:
- No agent or service process on the IRIS or Caché instance.
- No stored procedures, routines or helper classes installed into a namespace.
- No schema changes, no new tables, no new globals.
- No configuration change to the instance.
Everything the app displays comes from interfaces the instance already exposes. The performance scanners read index and constraint metadata and the cached query catalogue; the administration views read the same process, lock and log information the Management Portal reads. Uninstalling the app means deleting a directory — there is nothing left behind on any server to clean up.
Credentials
Connection passwords are stored encrypted in the per-user configuration on the local machine. They are never transmitted to us, never included in the update check or the activation request, and never written to a shared location. The single destination a connection password is ever sent to is the database server that connection points at.
If your policy does not permit stored credentials, leave the password empty and the app prompts for it when the connection is opened.
Deployment without a change request
Version 3.24 installs per user or runs from a portable ZIP. Neither route needs administrator rights, and neither writes outside your own profile and the directory you chose.
- Signed binaries, so the executable can be verified and allow-listed.
- A bundled private JRE 21, used only by this application. No system-wide Java to install or patch, no conflict with a different Java version another application needs, and no Oracle Java licensing question.
- Portable build, ~140 MB, for locked-down workstations, jump hosts and terminal servers where installing is not an option.
Installation options in detail →
Least privilege, and knowing which server you are on
The app is designed to be usable with a read-only database account. If your task for the day is reading data, connect with an account that can only read data — no feature silently requires more, and the ones that write will simply be refused by the server.
The other half of operational safety is human. Connections in the Server Navigator can be grouped and labelled, so a production server is visually distinct from the test instance next to it in the tree. It is a small thing that prevents the specific mistake everyone in this field has either made or narrowly avoided.
Encrypted connections: on the roadmap
Not supported today. TLS-encrypted database connections are on the published roadmap. We are not going to describe them as available before they ship, and we are not going to name a release or a date — a security feature promised for a specific version and then missing from it is worse than one that was never promised.
What that means in practice: today the JDBC connection is unencrypted at the transport layer, so it belongs on a trusted network, or behind a VPN or an SSH tunnel if the instance is not local. Credential storage on the client is a separate concern and is encrypted regardless. When TLS support ships it will be noted in what's new.
Questions your security review will ask
Does the application send any data about our databases, schemas or queries to a third party?
No. There is no telemetry, no usage analytics, no crash reporting service and no feature-usage tracking. Table names, column names, query text, result data and connection details never leave the machine the app runs on. The app reaches exactly two destinations — our update server and the LimeLM licence service — and neither carries anything about your databases.
What is installed on the database server?
Nothing. No agent, no service, no stored procedures or routines deployed into a namespace, no helper classes, no schema changes. SQL DATA LENS is a JDBC client: it connects, it runs statements you can read, it disconnects. Anything it shows you — cached queries, process lists, index definitions, global sizes — comes from catalogue and system views that already exist on the instance.
Where are connection passwords stored, and how?
In the per-user configuration on the local machine, encrypted. They are not stored in a shared location, not written to a central server, and not included in the update check or the activation request. The only place a connection password is ever sent is to the database you are connecting to.
If your policy forbids stored credentials outright, leave the password field empty and the app will prompt for it per session.
Does it require administrator rights, or a system-wide Java installation?
Neither. Install per user, or unzip the portable build into a directory you can write to — ~140 MB, Windows 10, 11 and Windows Server (64-bit). The binaries are signed. A private JRE 21 is bundled inside the application directory and used only by it, so there is no dependency on a system-wide Java, no version conflict with anything else on the workstation, and no Oracle Java licensing question to answer.
Can it run with a read-only database account?
Yes, and for read-only work that is the recommended setup. Browsing tables and globals, reading class source, viewing execution plans and running the performance scanners all work with a read-only account. Features that write — editing a cell, running DDL, purging a cached query, copying a class — will be refused by the server, as they should be. Nothing about the app assumes elevated rights.
Are database connections encrypted?
Not yet. TLS-encrypted connections are on the published roadmap; we will not claim support, or name a release, before the feature ships. Until then, treat the connection as unencrypted at the transport layer and protect it at the network layer — the usual approaches are a VPN or an SSH tunnel to reach an instance that is not on a trusted network. Credentials at rest on the client are a separate matter and are encrypted, as described above.
For the vendor questionnaire
If your procurement or information security process needs these answers on letterhead rather than on a web page, ask and you will get them. Write to sales@sqldatalens.com with the questionnaire or the specific list of questions, and you will receive a written response covering data flows, credential handling, deployment model and the current state of transport encryption. The privacy policy covers the website and the purchase process separately.
Next step
The claims above are the kind you can check yourself in twenty minutes. Download the portable ZIP onto a workstation, watch the network, and see what it does and does not do.
See your IRIS data the way it actually is
Download, unzip, connect. Your first namespace is on screen in about three minutes.
Windows 10, 11 and Windows Server (64-bit) · ~140 MB · version 3.24 · full 30-day Pro trial included