> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# PostgreSQL on Vortex IQ

> Monitor PostgreSQL health, cost and reliability signals, and catch incidents and runaway spend early.

Monitor PostgreSQL health, cost and reliability signals, and catch incidents and runaway spend early.

[Connect or manage this source](https://app.vortexiq.ai/workbench/settings/sources) · [How connecting works](/integrations/connector-catalogue) · [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=postgresql)

<CardGroup cols={5}>
  <Card title="31">
    performance signals
  </Card>

  <Card title="9">
    automated checks
  </Card>

  <Card title="Build your own">
    automated fixes
  </Card>

  <Card title="Ready to build yours">
    workflows
  </Card>

  <Card title="6">
    API operations
  </Card>
</CardGroup>

<Tabs>
  <Tab title="Overview">
    ### What you can achieve

    Capabilities are grouped around merchant outcomes, not API terminology.

    <CardGroup cols={2}>
      <Card title="Catalogue quality">
        Identify missing, inconsistent or outdated product data.
      </Card>

      <Card title="Protect revenue">
        Find failures, leaks and risks before they cost sales.
      </Card>

      <Card title="Run operations">
        Monitor orders, fulfilment, delivery and settlement.
      </Card>

      <Card title="Customer experience">
        Find storefront, speed, accessibility and journey problems.
      </Card>

      <Card title="Control risk and change">
        Keep tracking, access and change under governed control.
      </Card>

      <Card title="Grow revenue">
        Improve discovery, conversion, campaigns and repeat purchase.
      </Card>
    </CardGroup>

    ### From connection to verified outcome

    The controlled sequence every capability follows. Nothing changes a connected system without the approval step.

    <Steps>
      <Step title="Connect">
        Authorise the source. Scopes are shown before access is granted.
      </Step>

      <Step title="Monitor">
        Watch the signals against your own baselines, not universal defaults.
      </Step>

      <Step title="Detect">
        Run checks and gather evidence specific to your store.
      </Step>

      <Step title="Recommend">
        Explain what happened, why it matters and the proposed action.
      </Step>

      <Step title="Approve">
        You review scope, risk and reversibility before anything changes.
      </Step>

      <Step title="Execute">
        Apply through governed connector operations.
      </Step>

      <Step title="Verify">
        Confirm the intended result and keep the receipt.
      </Step>
    </Steps>

    No changes are made without the configured approval policy. Read-only operations do not modify the connected system; schedules, access scopes, API usage and data handling remain governed by Vortex IQ controls.
  </Tab>

  <Tab title="Monitor (31)">
    ### Monitor performance

    31 performance signals. Open an outcome to see its signals and how each one alerts. Read-only operations do not modify the connected system.

    <AccordionGroup>
      <Accordion title="Run operations (12 signals)">
        | Signal                                                       | Alert behaviour    | What it tracks                                                                                          |
        | ------------------------------------------------------------ | ------------------ | ------------------------------------------------------------------------------------------------------- |
        | **Active Streaming Replicas**                                | Watch only         | Description pending editorial review; the signal is live.                                               |
        | **Connection Pool at >90% Saturation**                       | Alert band 0 / 1   | Alerts for Connection Pool at >90% Saturation.                                                          |
        | **Connections In Use**                                       | Watch only         | Description pending editorial review; the signal is live.                                               |
        | **Database Disk Usage %**                                    | Alert band 70 / 90 | Description pending editorial review; the signal is live.                                               |
        | **Failover Readiness**                                       | Alert band 1 / 0   | Description pending editorial review; the signal is live.                                               |
        | **Instance Uptime**                                          | Watch only         | Seconds since pg\_postmaster\_start\_time(). Drop = unplanned restart.                                  |
        | **Last Successful Backup (hours ago)**                       | Alert band 24 / 72 | Last successful pg\_basebackup / WAL archive. For RDS: derived from CloudWatch backup events.           |
        | **Memory Usage %**                                           | Merchant rule      | Description pending editorial review; the signal is live.                                               |
        | **Queries per Second (live)**                                | Watch only         | Description pending editorial review; the signal is live.                                               |
        | **Replication Lag (seconds)**                                | Alert band 1 / 10  | Description pending editorial review; the signal is live.                                               |
        | **Replication Lag Exceeds Threshold or Standby Unreachable** | Alert band 0 / 1   | Alerts for Replication Lag Exceeds Threshold or Standby Unreachable.                                    |
        | **Top Tables by Dead Tuples**                                | Watch only         | n\_dead\_tup from pg\_stat\_user\_tables. Hot table accumulating dead tuples = needs autovacuum tuning. |
      </Accordion>

      <Accordion title="Protect revenue (7 signals)">
        | Signal                                                | Alert behaviour    | What it tracks                                                                                            |
        | ----------------------------------------------------- | ------------------ | --------------------------------------------------------------------------------------------------------- |
        | **Connection Pool Saturation %**                      | Alert band 70 / 90 | active+idle-in-tx / max\_connections. PgBouncer / pgpool pools tracked separately if present.             |
        | **Idle-in-Transaction Backends**                      | Alert band 5 / 10  | state='idle in transaction'. Stuck transactions hold locks + bloat the pool. PostgreSQL-distinctive risk. |
        | **Oldest Autovacuum Age (hours)**                     | Alert band 12 / 24 | Hottest table not vacuumed in >24h = autovacuum starved. PostgreSQL-distinctive , TXID wraparound risk.   |
        | **PgBouncer Pool Saturation vs Traffic Burst**        | Alert band 70 / 90 | PgBouncer Pool Saturation vs Traffic Burst, broken down by row.                                           |
        | **PostgreSQL Inventory Rows vs Ecom Inventory Count** | Merchant rule      | Description pending editorial review; the signal is live.                                                 |
        | **PostgreSQL QPS Spike vs Ecom Order Rate**           | Merchant rule      | Description pending editorial review; the signal is live.                                                 |
        | **Slow Queries During Checkout Window (5m)**          | Merchant rule      | Slow Queries During Checkout Window (5m), broken down by row.                                             |
      </Accordion>

      <Accordion title="Customer experience (6 signals)">
        | Signal                     | Alert behaviour      | What it tracks                                                                     |
        | -------------------------- | -------------------- | ---------------------------------------------------------------------------------- |
        | **Deadlocks (last 5m)**    | Alert band 0 / 5     | deadlocks column from pg\_stat\_database, delta over 5m window.                    |
        | **Query Latency p50 (ms)** | Watch only           | Description pending editorial review; the signal is live.                          |
        | **Query Latency p95 (ms)** | Alert band 50 / 200  | Description pending editorial review; the signal is live.                          |
        | **Query Latency p99 (ms)** | Alert band 100 / 500 | Description pending editorial review; the signal is live.                          |
        | **Slow-Query Rate %**      | Alert band 1 / 5     | Queries where mean\_exec\_time > 100ms as % of total calls (pg\_stat\_statements). |
        | **Top 10 Slowest Queries** | Watch only           | Top queries by total\_exec\_time from pg\_stat\_statements.                        |
      </Accordion>

      <Accordion title="Control risk and change (4 signals)">
        | Signal                                 | Alert behaviour    | What it tracks                                                                                          |
        | -------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------- |
        | **Connection Errors (24h)**            | Merchant rule      | Description pending editorial review; the signal is live.                                               |
        | **PostgreSQL Health Score**            | Alert band 80 / 70 | Composite: p95 latency healthy x error-free x replication-healthy x autovacuum-current x pool-headroom. |
        | **Query Error Rate %**                 | Alert band 0.1 / 1 | Description pending editorial review; the signal is live.                                               |
        | **Query Error Rate Spike (>1% in 5m)** | Alert band 0.1 / 1 | Alerts for Query Error Rate Spike (>1% in 5m).                                                          |
      </Accordion>

      <Accordion title="Catalogue quality (1 signals)">
        | Signal                      | Alert behaviour    | What it tracks                                                                                                       |
        | --------------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------- |
        | **Buffer Cache Hit Rate %** | Alert band 95 / 80 | blks\_hit / (blks\_hit + blks\_read) from pg\_stat\_database. \<95% on production OLTP = shared\_buffers undersized. |
      </Accordion>

      <Accordion title="Grow revenue (1 signals)">
        | Signal                                 | Alert behaviour                   | What it tracks                                                                                         |
        | -------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------ |
        | **WAL Lag Bytes (primary -> standby)** | Alert band 104857600 / 1073741824 | pg\_wal\_lsn\_diff(primary, standby) , bytes still to ship. Sustained growth = standby falling behind. |
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="Audit (9)">
    ### Audit risks and opportunities

    A fix status appears only where the action, inputs, approval, verification and recovery controls are mapped. Candidate remediations are never executable. Open a check for the detail.

    <AccordionGroup>
      <Accordion title="Connection pool saturation above 90%">
        **Severity** critical · **Outcome** Customer experience · **Fix status** Report only

        At 90% of the connection pool in use, the database is close to refusing new connections outright. Once it does, every part of the application that needs a fresh database connection, including new customer sessions and checkout, starts failing, not just slowing down.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-CAP-001`
      </Accordion>

      <Accordion title="Disk usage above 90%">
        **Severity** critical · **Outcome** Run operations · **Fix status** Report only

        A database that runs out of disk stops accepting writes entirely, which for most stores means orders, inventory updates and customer records stop being saved, not just that the database gets slower. There is very little runway left at 90%.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-CAP-002`
      </Accordion>

      <Accordion title="Query error rate above 1% in last 5 minutes">
        **Severity** critical · **Outcome** Run operations · **Fix status** Report only

        More than 1 in 100 queries is failing right now. Depending on what those queries do, this can mean orders not saving, pages failing to load product or customer data, or background jobs silently dropping work, and a rate this high in a 5-minute window is an active incident, not background noise.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-ERR-001`
      </Accordion>

      <Accordion title="Last successful backup older than 72 hours">
        **Severity** high · **Outcome** Run operations · **Fix status** Report only

        If something goes wrong with this database right now, the most recent point it can be restored to is over 3 days old. Every order, customer record and inventory change since that backup would be unrecoverable in a real incident, not just delayed.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-BAK-001`
      </Accordion>

      <Accordion title="Replication lag above 10 seconds">
        **Severity** high · **Outcome** Run operations · **Fix status** Report only

        Anything reading from the replica, reports, dashboards, or read traffic split off the primary for capacity, is now up to 10+ seconds stale. If the primary fails while lag is this high, the replica is also that far behind on failover, which is a bigger problem than the staleness alone.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-REP-001`
      </Accordion>

      <Accordion title="Slow-query rate above 5% of total">
        **Severity** high · **Outcome** Customer experience · **Fix status** Report only

        More than 1 in 20 queries is landing in the slow bucket. That is frequent enough to be a pattern, not noise, and it means a meaningful share of every page load or job that touches this database is paying the slow-query cost, not just an unlucky occasional request.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-PERF-002`
      </Accordion>

      <Accordion title="p95 query latency above 200ms sustained 15m">
        **Severity** high · **Outcome** Customer experience · **Fix status** Report only

        One in twenty queries against this database is taking over 200ms, sustained for at least 15 minutes, not a brief spike. Any storefront page, checkout step or order sync that depends on this database inherits that slowness directly, and a sustained p95 this high is usually already visible to customer

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-PERF-001`
      </Accordion>

      <Accordion title="Buffer / cache hit rate below 80%">
        **Severity** medium · **Outcome** Run operations · **Fix status** Report only

        More than 1 in 5 reads is missing the cache and going to disk instead, which is markedly slower. This shows up as everything the database does feeling incrementally heavier, rather than as one obvious failure.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-CACHE-001`
      </Accordion>

      <Accordion title="Deadlocks detected (>0 in last 5 minutes)">
        **Severity** medium · **Outcome** Protect revenue · **Fix status** Report only

        A deadlock means two operations blocked each other and the database had to kill one of them; whatever that transaction was doing (placing an order, updating stock, writing a record) failed and, depending on how the application handles it, may not have been retried.

        Vortex IQ detects and explains this; resolution is manual, with evidence and recommended steps.

        Reference: `DB-PERF-003`
      </Accordion>
    </AccordionGroup>

    #### Build your own automated fixes

    Turn any finding into an automated fix with a Vortex IQ workflow: **over 13,000 read and write operations across more than 200 connectors** are available as building blocks, with approval, verification and rollback on every change.
  </Tab>

  <Tab title="Automate">
    ### Automate approved work

    Vortex IQ is integrated with **6 read** and **0 write** operations across pgsettings, pgstatactivitys, pgstatdatabases, pgstatreplications, pgstatstatements, pgstatusertables on PostgreSQL. Combine them with anything from the **over 13,000 operations across more than 200 connectors** to automate the work in your own words.

    Changes follow your configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution.

    [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=postgresql)

    #### Ready to build your first PostgreSQL workflow

    Pick a trigger, add the operations above as steps, and every step that changes data pauses for your approval. Monitoring and audits are live now and can start any workflow you build.

    <Accordion title="Browse the operations you can build with">
      | Resource           | Read operations | Write operations |
      | ------------------ | --------------- | ---------------- |
      | pgsettings         | 1               | 0                |
      | pgstatactivitys    | 1               | 0                |
      | pgstatdatabases    | 1               | 0                |
      | pgstatreplications | 1               | 0                |
      | pgstatstatements   | 1               | 0                |
      | pgstatusertables   | 1               | 0                |

      Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected.
    </Accordion>
  </Tab>
</Tabs>