What are iDBQuery's data retention and deletion policies?

Retention is simpler with iDBQuery than with a warehouse-based stack, because there's far less to retain in the first place.

Since iDBQuery queries your sources in place and builds a live model over them, your underlying records stay in your own databases and files — iDBQuery isn't a second permanent copy of them. What it does hold is operational:

• Connection configuration and encrypted credentials for each source.
• Schema metadata and the semantic layer it learns so it can understand your data.
• Cached results, reports and dashboards you've created.
• Audit and activity logs.

You stay in control of all of it. Removing a source deletes its stored metadata, cached results and credentials. Deleting a workspace removes its associated stored data. When you cancel, you can export what you've built and then have the workspace deleted.

Deployment changes the picture entirely. In a self-hosted, single-server or air-gapped deployment, every one of these artefacts lives inside your own infrastructure, so retention periods, backups and deletion are governed by your policies, not ours — there is no copy sitting in a vendor cloud to worry about. This is also what makes iDBQuery straightforward to align with data-subject deletion requests: you can trace a figure to its exact source rows, and you control where any derived data is stored and when it's purged.