PostgreSQL monitoring in Saudi Arabia: Redgate Monitor beside your SQL Server estate

Most PostgreSQL incidents start small: one query that got slower after a data load, autovacuum falling behind on a busy table, a standby drifting further from the primary, a disk filling with write-ahead log. Good postgres performance monitoring catches these while they are still small, and points to the cause rather than only the symptom.

Redgate Monitor reads query statistics from pg_stat_statements and lists the top queries in any time window, ranked by execution count, duration, IO time or blocks read, as a total or an average per execution. You can search by query text and follow one query's history over days.

For postgresql slow queries, the plan matters as much as the timing. Redgate Monitor shows the latest plan that auto_explain captured, as a node graph, so a DBA can see where the time went. Redgate's preparation guide sets auto_explain to log plans for statements that take longer than two seconds; we agree that threshold with you, because plan logging has a cost on busy systems.

Vacuum and table sizes. For each table Redgate Monitor shows its size, its dead tuples and whether the autovacuum daemon is enabled, and it raises a table bloat alert when vacuuming is not working. Redgate's product page also describes an alert when transaction ID usage passes a threshold you set.

Replication. On a primary, Redgate Monitor charts lag for each replica, broken down into pending, write, flush and replay, and lists replication slots, highlighting slots with no limit on retained write-ahead log. On a standby, it charts incoming lag.

Many organisations in Saudi Arabia run SQL Server for older systems and PostgreSQL for newer applications, often with a different team for each. Redgate Monitor puts both in one web-based view, grouped the way your teams work, with one set of alert rules, notification routes and reports.

If you already run Redgate Monitor for SQL Server, PostgreSQL is added to the same installation; our SQL Server monitoring page covers that side. During a move from SQL Server, watching both lets you compare the old and new systems; see our PostgreSQL migration service.

Where teams use it:

• Mixed estates looked after by one DBA team.
• Managed PostgreSQL on RDS, Aurora or Cloud SQL, watched at query level.
• High-availability clusters, with replication lag charted.

RelatedSQL Server monitoring page

Redgate Monitor monitors PostgreSQL on your own Linux or Windows servers and on managed services: Amazon RDS and Aurora, Azure Flexible Server, Google Cloud SQL and AlloyDB. On Linux it connects to the host over SSH, with password or key authentication and no root privilege. On managed services it reads the provider's metrics and logs through the access the provider allows, such as a Google service account with viewer roles.

Interkey implements both, and they serve different teams. Redgate Monitor is built for DBAs who look after a database estate, with backups, configuration and SQL Server side by side. If your teams already run Datadog for applications and infrastructure, Datadog Database Monitoring, which Datadog documents for Postgres, keeps query metrics and plans in the same platform as traces and logs. Settle who owns each database alert first; the tool follows from that.

Redgate prices the Standard edition per server, per year. On Redgate's terms a cloud PaaS licence covers one node, and in multi-node set-ups such as Aurora clusters each monitored node needs its own licence. The Enterprise edition is priced by Redgate on request, and Redgate offers a 14-day free trial. Interkey quotes the implementation, and any operation, as a fixed scope, with Redgate licensing shown beside it at the vendor's terms.

The timeline is an estimate. Installing Redgate Monitor and connecting the first instances is usually the short part. What drives the rest is the number of instances, how quickly the preparation restarts can be scheduled, and how long alert tuning takes across many server groups.