No production database connection
QueryBolt works from the schema, SQL and representative row-count or sample information a customer submits. It does not require production database credentials.
Security & trust
Security at QueryBolt.
How QueryBolt handles customer SQL, isolates benchmarks, protects accounts, and works with third-party providers.
No production credentials required
Temporary benchmark databases
Customer-controlled query history
This page describes controls implemented for QueryBolt. It does not claim that QueryBolt or Vistra Nova Ltd is currently SOC 2 or ISO 27001 certified. Provider certifications apply to those providers, not automatically to QueryBolt.
Controls
Designed for sensitive database work
Controls focus on minimising what customers must share, constraining where submitted workloads execute, and making stored data removable.
Isolated benchmark environments
Optimization jobs run in per-job temporary databases with constrained database users. Temporary databases are designed to be removed after processing, with scheduled cleanup as a fallback.
Encryption and secrets
Customer traffic is protected with HTTPS/TLS. Production database storage and backups are configured for encryption at rest, and deploy credentials are held outside source control.
Account and application controls
Passwords are bcrypt-hashed. Sessions have idle and absolute expiry, sensitive requests use CSRF protection, and authentication and abuse paths are rate-limited.
Change and dependency controls
Changes are reviewed through pull requests and automated tests. Production deploys run migrations and health checks, while dependency versions and security fixes are tracked in source control.
Retention and customer control
Customers can export or delete account data and control saved query history. Jobs, results and execution logs use documented retention periods and scheduled pruning.
Data flow
What happens to an optimization
QueryBolt benchmarks a customer-provided workload without connecting to the customer’s live database.
01 · Submit
Customer chooses the input
Schema, SQL and representative row counts or sample data are submitted over HTTPS.
02 · Isolate
Per-job temporary database
The job is scoped to its own temporary database using constrained runtime credentials.
03 · Benchmark
Compare measured results
Candidate rewrites are measured and the evidence is stored with the customer-scoped job.
04 · Remove
Clean up temporary data
The temporary database is dropped after processing; scheduled cleanup covers interrupted jobs.
Documents
Review before you buy
Public documentation for security reviewers, privacy teams and procurement.
Responsible disclosure
Found a security issue?
Please report it privately. Include the affected URL or feature, reproducible steps and potential impact, but do not include another customer’s data or continue testing in a way that degrades the service.
Machine-readable disclosure details: /.well-known/security.txt
Last updated 1 September 2026. Questions from security or procurement teams can also be sent through contact support.