Databases supported by QueryAlerts
QueryAlerts was designed to work with the main databases used by sales, finance, logistics, and management teams. With one local-agent model, you connect the database, publish the queries, and turn results into email and WhatsApp alerts.
Which databases are supported today
Today, the QueryAlerts local agent supports Oracle, PostgreSQL, MySQL, and SQL Server. That covers a large share of the databases commonly found behind ERPs, internal systems, sales operations, and corporate environments where SQL follow-up is part of the daily workflow.
In practice, that means different teams can adopt the same alerting flow even when they work on different database technologies. The operating model stays the same: configure access in the agent, publish the query in the dashboard, and let execution happen automatically on schedule.
- Oracle
- PostgreSQL
- MySQL
- SQL Server
What that changes in practice
Supporting multiple databases reduces the need to create separate workflows for each environment. If the company uses Oracle in the core ERP, PostgreSQL in web systems, MySQL in legacy apps, or SQL Server in internal reporting, the team can centralize operational follow-up in the same product.
That also improves standardization. Teams learn one way to write queries, define schedules, configure recipients, and review execution history, regardless of which database is behind that specific routine.
- One workflow across different databases
- Standardized alerts across systems
- More predictable operations
- Less manual follow-up in mixed environments
Examples of use across different databases
In Oracle, common monitoring scenarios include blocked orders, daily revenue, and receivables close to due date. In PostgreSQL, teams often track events from web systems, queues, subscriptions, or SaaS operations. In MySQL, recurring use cases include ecommerce orders, stock, inactive customers, and catalog health. In SQL Server, it is common to monitor internal processes, operational BI, and business systems tied to Microsoft environments.
The important point is that the product does not depend on one single use case or one single database. Its value is in turning SQL queries into automated follow-up, whatever database powers the operation.
How connection works in the agent
During setup, the local agent receives the connection settings according to the selected database type. For Oracle, that includes the service name. For the other databases, that usually means host, port, user, password, and database name when applicable. From there, the agent validates connectivity and starts executing the queries synchronized from the dashboard.
Because execution happens inside the customer environment, QueryAlerts keeps the same security model across every supported database: access remains local, the database does not need to be publicly exposed, and the SaaS only receives what is necessary for execution history and notification delivery.
Why this matters as operations grow
Companies rarely run everything on a single database forever. As operations grow, new systems appear, acquisitions happen, legacy tools stay alive, and different databases end up coexisting. Supporting multiple databases in the same product prevents each team from needing a separate alerting solution.
That makes rollout easier, reduces friction with IT, and creates a more consistent routine for the business. Instead of relying on people to remember which report to open in which database, teams receive the relevant alert in the right channel at the right time.
Ready to turn queries into alerts?
Create your account, connect the local agent, and publish your first queries without exposing the customer database.