Security in QueryAlerts
The QueryAlerts architecture was designed to keep database access inside the customer environment, using a local agent to run queries and send only the data required for notification delivery.
Security starts with architecture, not just messaging
For products that depend on customer databases, the most important security decision is usually architectural. If the platform requires direct internet-facing access to the database, operational risk and IT complexity both increase. QueryAlerts is designed in the opposite direction: keep execution close to the database and minimize exposure as much as possible.
That means customers do not need to turn their database into a public service to use alerts and automations. Most sensitive processing stays inside the authorized environment, while the SaaS acts as the layer for configuration, history, and notification delivery.
Database stays private
The SaaS does not need direct access to the customer database. The local agent runs the query inside the authorized environment and sends only the required result.
- No need to publicly expose the database
- Queries run inside the customer network
- Less dependence on inbound firewall exceptions
Credentials stay in the agent
Customer database credentials are stored in the agent local SQLite database, not in the QueryAlerts server.
- Credentials remain in the local environment
- Separation between database access and the SaaS dashboard
- Less circulation of sensitive data outside customer infrastructure
Communication with the SaaS
Communication between the agent and the SaaS happens over HTTPS and shared-secret validation.
- Periodic query synchronization
- Heartbeat for agent health and status
- Result delivery for notification fan-out
What actually goes to the platform
The goal is not to mirror the entire database into the SaaS. The agent runs the published queries and returns what is necessary to record the execution, evaluate the rule, and trigger the configured notification. That helps keep traffic more controlled and aligned with the product use case.
In practice, teams use the platform to manage alerts, history, and configuration, while raw database access remains restricted to the environment where it already belongs.
Benefits for IT and governance
This model usually makes discussions with infrastructure, security, and governance teams easier because it reduces the need to expose ports, create broad network exceptions, or share direct access with external services.
Operationally, it also creates a practical advantage: the company can automate follow-up workflows and alerts without giving up control over where queries run and where credentials are stored.
- More predictable technical approval path
- Less friction with internal security policies
- Automation without giving up local control
Ready to turn queries into alerts?
Create your account, connect the local agent, and publish your first queries without exposing the customer database.