How to Monitor pgvector with Vigilmon

pgvector is the open-source PostgreSQL extension that enables vector similarity search directly inside Postgres using ivfflat and HNSW indexing. Rather than adding a dedicated vector database, teams using pgvector store embeddings alongside relational data in their existing Postgres instance — powering retrieval-augmented generation (RAG) pipelines, semantic search features, and recommendation systems. When the PostgreSQL instance running pgvector goes down, your RAG pipeline loses the ability to retrieve relevant context, your semantic search returns zero results, and any embedding-backed feature silently degrades. Vigilmon gives you external uptime monitoring for the HTTP API layer in front of your pgvector deployment — REST endpoint availability, SSL certificate validity, and alerting before your vector search infrastructure stops serving queries.

What You'll Build

• An HTTP monitor on the API service fronting your pgvector-enabled Postgres instance
• A monitor on the vector search query endpoint to catch search-layer failures
• A TCP monitor on the Postgres port for direct database availability checks
• An SSL certificate monitor for your pgvector API domain
• Alerting rules that notify your team when vector similarity search stops working

Prerequisites

• A pgvector deployment accessible through an HTTP API layer — PostgREST, a custom FastAPI/Express wrapper, or a managed service like Supabase
• The API endpoint network-reachable from Vigilmon probes
• A free account at vigilmon.online

Step 1: Understand pgvector's External Monitoring Surface

pgvector itself is a PostgreSQL extension, not a standalone HTTP service. Vigilmon monitors HTTP and TCP endpoints, so monitoring focuses on the layers that expose your vector search capabilities externally:

| Component | Typical path | Role | |---|---|---| | PostgREST / API health | / or /health | Confirms the REST layer serving Postgres is running | | Vector search endpoint | /documents or /embeddings | Returns rows from the pgvector table via REST | | Postgres TCP port | :5432 | Direct TCP availability of the Postgres server | | Supabase REST API | /rest/v1/ | Managed Supabase HTTP layer over pgvector | | Custom health endpoint | /pgvector-health | Application-defined probe that checks extension and index status |

For Supabase (which includes pgvector), the monitoring target is the Supabase REST API. For self-hosted setups using PostgREST, the target is your PostgREST instance.

Step 2: Monitor the PostgREST / API Health Endpoint

PostgREST exposes a root endpoint that confirms the REST-to-Postgres bridge is alive. If this endpoint is unreachable, no vector queries can reach pgvector:

curl -I https://api.example.com/
# Returns 200 with application/json content — PostgREST root schema listing

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://api.example.com/ (your PostgREST base URL, e.g. https://myapp.supabase.co/rest/v1/ for Supabase).
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Label: pgvector API layer.
7. Click Save.

This monitor catches:

• PostgREST container crashes or restart loops
• Postgres connection pool exhaustion preventing PostgREST from connecting
• Network misconfiguration isolating the API layer from Postgres
• Deployment failures on the API service fronting pgvector

Alert sensitivity: Set to trigger after 1 consecutive failure. An API layer outage means every vector search query in your application fails immediately.

Step 3: Monitor the Vector Search Endpoint

The search endpoint is the path your application hits to perform vector similarity queries. An HTTP GET with a sample query confirms the full vector search path is functional:

curl -I "https://api.example.com/documents?select=id,content&limit=1"
# Returns 200 with JSON — confirms PostgREST can query the pgvector table

1. Add Monitor → HTTP.
2. URL: https://api.example.com/documents?select=id&limit=1 (replace documents with your pgvector table name).
3. Check interval: 2 minutes.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Label: pgvector search endpoint.
7. Click Save.

Supabase users: Use https://<project>.supabase.co/rest/v1/<table>?select=id&limit=1 with an apikey header. For monitoring purposes, use a read-only anon key to avoid exposing service role keys in monitor configuration.

Step 4: Monitor PostgreSQL TCP Availability

For direct visibility into whether the Postgres server running pgvector is accepting connections, add a TCP monitor on port 5432:

1. Add Monitor → TCP.
2. Host: db.example.com (your Postgres host, e.g. db.<project>.supabase.co for Supabase).
3. Port: 5432.
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Postgres (pgvector) TCP.
7. Click Save.

Network access note: Vigilmon's probes must be able to reach your Postgres host on port 5432. Many production setups restrict Postgres TCP access to application servers only. If direct TCP monitoring is not feasible, rely on the HTTP API monitors in Steps 2 and 3.

Step 5: Monitor SSL Certificates

Your pgvector API layer's TLS certificate protects both data in transit and client trust. An expired certificate causes your application's HTTP clients to reject connections before any vector query reaches Postgres:

openssl s_client -connect api.example.com:443 2>/dev/null | openssl x509 -noout -dates

1. Add Monitor → SSL Certificate.
2. Domain: api.example.com (your PostgREST or API gateway domain).
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

Managed services: Supabase manages SSL certificates automatically. If using a custom domain in front of Supabase, monitor the custom domain certificate separately — Supabase's base domain certificate renewal does not cover your custom domain.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | pgvector API layer | Non-200 or timeout | Check PostgREST container; inspect Postgres connection pool; review application logs | | Vector search endpoint | Non-200 or timeout | Table may be missing or renamed; check pgvector extension status in Postgres | | Postgres TCP | Connection refused or timeout | Postgres server down; check disk space, OOM, or pg_hba.conf misconfigurations | | SSL certificate | < 30 days to expiry | Renew certificate; test application clients can still connect after renewal |

Alert after: 1 consecutive failure for the API layer monitor. 2 consecutive failures for the search endpoint and TCP monitors.

Common pgvector Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Postgres OOM killed | TCP monitor fires; all vector searches fail | | Disk full (WAL or data volume) | Postgres stops accepting writes; API monitor returns errors | | PostgREST crash or restart loop | API health monitor fires; search endpoint returns 503 | | pgvector extension dropped accidentally | Search endpoint returns 500 on vector operators | | Connection pool exhausted (high embedding traffic) | API monitor times out or returns 503 | | SSL certificate expired on API gateway | SSL monitor alerts at 30-day threshold; clients reject connection | | HNSW index rebuild in progress (high CPU) | Search endpoint response times spike; Vigilmon timeout alert fires | | Network policy change blocks API layer | API monitor fires; RAG pipeline context retrieval fails | | Postgres vacuum lock blocking queries | Search endpoint slow or timing out; timeout alert fires | | Postgres version upgrade with incompatible pgvector | API returns 500 on vector queries; search endpoint monitor fires |

HTTP Availability vs. Vector Search Correctness

Vigilmon monitors whether your pgvector API layer is reachable — it does not verify whether vector similarity search is returning semantically correct results. For deeper pgvector quality monitoring:

• Index staleness: HNSW and ivfflat indexes need periodic rebuilding after large ingestion batches — a healthy API endpoint can return degraded recall if indexes are stale.
• Embedding dimension mismatch: A configuration change to your embedding model may produce vectors with incompatible dimensions — Postgres will reject inserts but existing search may still work; monitor your ingestion pipeline separately.
• Query latency: For latency-sensitive RAG pipelines, add Vigilmon response time alerts to detect when pgvector queries are slow before timeouts occur.

Vigilmon catches infrastructure-level failures — endpoint unreachability, Postgres TCP outages, certificate expiry. Search quality and index health require application-level metrics alongside external uptime monitoring.

pgvector brings vector search into your existing Postgres stack, but the Postgres instance and API layer powering it need monitoring. An outage takes down your RAG pipeline's context retrieval, semantic search features, and any embedding-backed recommendation systems simultaneously. Vigilmon checks your pgvector API layer, search endpoint, TCP port, and SSL certificate on a 60-second cycle, so you know within a minute when your vector search infrastructure stops serving queries.

Start monitoring pgvector in under 5 minutes — register free at vigilmon.online.