How does iDBQuery encrypt data in transit and at rest?

iDBQuery encrypts data in transit with TLS on every connection between your browser, the application and your data sources, and any data it stores — such as credentials, cached results and metadata — is encrypted at rest. In air-gapped and self-hosted deployments encryption runs entirely within your own infrastructure.

Encryption in iDBQuery works on two fronts, and the deployment model shapes how much stays under your direct control.

  • In transit: connections between your browser, the iDBQuery application and each connected source are protected with TLS, so data moving over the network is encrypted end to end. Source credentials are transmitted over encrypted channels.
  • At rest: anything iDBQuery persists — connection credentials, schema metadata, semantic-layer definitions and cached results — is stored encrypted. Credentials in particular are held in an encrypted secret store rather than in plain text.

The bigger security lever, though, is iDBQuery's query-in-place architecture. Instead of force-copying your databases into a separate warehouse, iDBQuery queries your sources where they already live and builds one live model over them. That means far less of your data is ever duplicated or moved in the first place — the smallest attack surface is the data you never copied.

For the strictest requirements, you can run iDBQuery inside your own VPC, on a single on-premise server, or fully air-gapped, and use the Desktop app or Embedded SDK to keep data local. In those modes, encryption keys and stored data remain entirely inside your environment, with no dependence on our cloud. This lets you meet demanding internal encryption standards without taking our word for it — the whole system runs where you can inspect it.

Updated 2026-06-22