The database restored cleanly. The application came back. Then support search returned old policy chunks, missed the latest incident runbooks, and mixed two embedding model versions in the same result set. The backup met the database RPO. It failed the retrieval RPO.

Short Version

pgvector changes recovery planning because embeddings are both data and derived data. The rows may live in Postgres, but the operational question is whether the retrieval system can be restored to a known semantic state.

RPO and RTO need separate answers for source records, chunk rows, embedding vectors, vector indexes, and query-quality validation. A restore is not complete when PostgreSQL starts. It is complete when authorized users can retrieve the right documents, deleted documents stay hidden, and the rebuilt or restored vector indexes behave within an accepted tolerance.

For every pgvector RAG system, decide whether embeddings are recoverable state, rebuildable derived state, or both. That decision drives backup size, restore time, index rebuild time, model-version retention, and DR runbooks.

Situation

PostgreSQL backup plans usually prove that a database can be restored to a consistent point in time. RAG systems need that, but they also need the retrieval layer to come back with the right corpus, model version, indexes, and authorization behavior.

The Problem

Traditional Postgres backup plans focus on transactionally correct recovery: base backups, WAL, point-in-time restore, replica promotion, and application reconnects. RAG adds another layer:

  • Source documents may be restored to one point in time.
  • Chunk tables may represent a deterministic transformation of those documents.
  • Embeddings may depend on an external model version.
  • Vector indexes may take significant time to rebuild.
  • Query results may change after rebuild even when rows are present.
  • Authorization failures can leak restored chunks from deleted or moved tenants.

This creates a subtle recovery trap. If embeddings are backed up as ordinary rows, restore may be storage-heavy but straightforward. If embeddings are treated as rebuildable, restore may be smaller but RTO depends on re-chunking, re-embedding, rate limits, model availability, and index build time.

Neither answer is universally correct. The mistake is not choosing.

Core Technical Explanation

A production pgvector schema usually has at least four recovery surfaces:

flowchart TD
    Source[source records] --> Chunks[chunk rows]
    Chunks --> Embeddings[embedding vectors]
    Embeddings --> Index[pgvector index]
    Source --> Backup[database backup]
    Chunks --> Backup
    Embeddings --> Backup
    Index --> Rebuild[index rebuild]
    Backup --> Restore[restore drill]
    Rebuild --> Validate[retrieval validation]
    Restore --> Validate

The base table is the business truth: documents, owners, tenants, lifecycle state, permissions, and deletion markers. Chunk rows are a projection of that truth. Embeddings are a numerical representation of chunk text under a specific model, dimension, and preprocessing pipeline. The vector index is an access path over those embeddings.

Backup and restore planning depends on which of those surfaces you preserve.

If you back up embeddings, you preserve the exact vectors from the backup point. That supports faster recovery if the database restore is enough and the index is still usable or can be rebuilt quickly. The cost is larger backups, larger restores, more storage, and more WAL.

If you rebuild embeddings, you need reproducible chunking, retained source text, retained model identity, access to the embedding model, and enough batch capacity. That can reduce backup dependence on derived vectors, but it moves RTO into the ingestion pipeline.

Vector indexes are a third concern, and the split follows PostgreSQL’s general backup taxonomy. A physical backup (pg_basebackup or a filesystem/WAL-based snapshot) copies the data directory as-is, so index relation files — including HNSW and IVFFlat indexes — restore intact with no rebuild needed. A logical backup (pg_dump) stores only the CREATE INDEX statements, not the index data itself, so every index, vector or otherwise, is rebuilt from scratch on restore — and an HNSW rebuild on a large embedding table is a materially different time cost than rebuilding a B-tree. Migration paths that use logical dump-and-restore (major-version upgrades, some managed-service migration tools) inherit this rebuild cost; confirm which backup method a given DR path actually uses before estimating RTO.

In Practice

The most robust operating model separates recovery ownership:

Source-of-truth owner. Defines which records must be recoverable, which deletes are permanent, and what point in time matters for business correctness.

Embedding pipeline owner. Owns chunking code, model version, dimensions, batching, idempotency, and rebuild throughput.

Database owner. Owns backup schedules, WAL retention, restore procedures, index rebuild windows, and query-plan validation.

Product owner. Defines acceptable retrieval degradation during recovery. Some systems can run lexical fallback for a few hours. Others cannot answer without semantic retrieval.

Store recovery metadata in the database:

-- Sketch only; adapt to the local schema.
CREATE TABLE embedding_batches (
  id bigserial PRIMARY KEY,
  embedding_model text NOT NULL,
  model_dimension int NOT NULL,
  chunker_version text NOT NULL,
  started_at timestamptz NOT NULL,
  completed_at timestamptz,
  source_snapshot text
);

The point is not the exact table. The point is to make recovery inspectable. During an incident, the team should be able to answer which model produced the vectors, whether a backfill completed, and which chunks are stale.

Where It Breaks

Failure modeWhy it hurtsMitigation
Embeddings treated as disposable without rebuild capacityRestore finishes but search remains degraded for daysMeasure rebuild throughput before relying on it
Embeddings backed up without model metadataRestored vectors cannot be compared or regenerated safelyStore model, dimension, chunker, and content hash
Index rebuild omitted from RTODatabase is online but retrieval queries are too slowInclude index build time in restore drills
Deleted documents restored into retrievalSecurity incident after point-in-time restoreReplay deletes or validate lifecycle filters
Mixed model versions after partial restoreRanking quality changes silentlyQuery by model version and isolate migrations
DR region lacks embedding provider accessRebuild runbook fails outside primary regionPre-approve provider access and secrets

Security and Tenancy Notes

Backup and restore can break tenant boundaries when restored data is routed through a different environment. A DR drill should verify tenant filters, row-level policies if used, application roles, and secret scoping.

Embedding content deserves the same classification as source text. Even if vectors are not human-readable, retrieval can expose the underlying sensitive text. Backups containing embeddings should inherit the data-retention and encryption requirements of the source corpus — this is a policy decision for the team’s own data classification framework, not a pgvector-specific setting, so it needs sign-off from whoever owns compliance for the source corpus rather than a database-team default.

For tenant deletion, decide whether a restored point in time is allowed to bring back deleted tenant chunks. If not, the runbook needs a post-restore deletion replay or a tombstone source that survives restore.

Cost Notes

Embedding recovery cost appears in three places.

First, storage and backup cost increase when vectors are stored as ordinary database rows. Second, restore cost increases when large vector tables and indexes extend recovery time. Third, rebuild cost appears as embedding API spend, worker compute, database writes, and index maintenance.

Do not compare “backup embeddings” against “rebuild embeddings” as if rebuild is free. Rebuild has a cloud bill and an operational bill.

Observability Notes

Useful recovery metrics include:

  • Backup age and restore test age.
  • Vector table size, index size, and growth rate.
  • Embedding freshness lag by corpus and tenant.
  • Count of chunks by model version and chunker version.
  • Rebuild throughput in chunks per minute.
  • Index build duration in staging and production.
  • Query latency during degraded mode.
  • Retrieval validation pass rate after restore.

Keep a small fixed query set for recovery validation. It should include tenant-specific queries, deleted-document negative tests, exact identifier queries, and semantic queries that depend on embeddings.

Backup, Restore, and DR Notes

Write the runbook in phases:

  1. Restore the database to the target point in time.
  2. Confirm schema, extensions, roles, and vector columns.
  3. Confirm embedding model versions present in restored rows.
  4. Rebuild or validate vector indexes.
  5. Replay tombstones or post-restore corrections if required.
  6. Run retrieval validation queries.
  7. Resume embedding workers in controlled mode.
  8. Watch lag, query plans, and error rates.

For DR, predefine degraded modes. A support assistant may run lexical search only. A compliance retrieval system may need to stay down until semantic validation passes. A customer-facing RAG feature may need a banner or feature flag if freshness is behind.

Decision Checklist

  • Are embeddings backed up, rebuilt, or both?
  • Is chunking deterministic across deploys?
  • Are model version, dimension, content hash, and chunker version stored?
  • Has index rebuild time been measured on realistic data?
  • Can the embedding provider be reached from the DR environment?
  • Are deletes and tenant moves replayable after point-in-time restore?
  • Does the runbook include retrieval-quality validation?
  • Is there a degraded mode when vector search is unavailable?
  • Are backup retention and encryption policies aligned with source data classification?

What to Do Next

Problem: A database restore that meets the PostgreSQL RPO/RTO can still fail the retrieval RPO — old chunks reappear, model versions mix, or deleted documents come back searchable.

Solution: Decide explicitly whether embeddings are recoverable state (backed up as rows) or rebuildable state (regenerated from source), store model/dimension/chunker metadata to make that decision inspectable, and include index rebuild time and retrieval validation in RTO — not just database uptime.

Proof: A restore drill runs the fixed recovery query set (tenant-specific queries, deleted-document negative tests, semantic queries) and passes before the team declares recovery complete.

Action: This week, confirm whether the last restore drill validated retrieval quality or only database availability, and add the missing validation step if it didn’t.

Sources to Verify