How does iDBQuery make sure it never writes to or deletes my data?
iDBQuery only issues read queries and validates generated SQL against a deny-list that blocks writes, drops, and other data-changing statements. Paired with a read-only database user, that gives two layers of protection — one in the app, one enforced by your database — so your data can be queried but never altered.
Letting an AI generate SQL raises an obvious question: could it ever run a destructive command? iDBQuery is built so the answer is no.
- Read-only by design. The product exists to analyse, so it generates `SELECT`-style read queries, not `INSERT`, `UPDATE`, `DELETE`, or `DROP`.
- SQL validation. Generated SQL passes through validation that rejects data-modifying and unsafe statements before anything runs, so a malformed or manipulated query can't slip through.
- Least-privilege credentials. Connecting with a read-only database user makes the guarantee absolute at the source: even if something unexpected were attempted, the database itself would refuse it.
Together these give defence in depth — a control in iDBQuery and a control in your own infrastructure. It's the same philosophy behind query-in-place and deploy-anywhere: keep the tool's footprint tightly bounded and keep your data under your control. For extra assurance, iDBQuery keeps audit logs of activity, and every answer shows the exact read query it ran, so you can confirm for yourself that only safe, non-destructive SQL was executed.
Updated 2026-06-22