RDS & PostgreSQL on AWS

RDS & PostgreSQL on AWS is the managed Postgres — the production data home (L268) — the instance (the compute and the storage, L268), the multi-AZ (the synchronous standby for the availability, L261), the backups (the snapshots and the point-in-time recovery, L304), and the pgvector extension (the vector store inside Postgres, L183) — the chat history (L166), the users and the tenants (L320), and the vectors (L183) all live here (L268).

The one-sentence interview answer: "RDS is AWS's managed relational database (L268). Postgres on RDS is the production default (L268): the instance — the compute and the storage you choose (L268); the multi-AZ — a synchronous standby in another AZ (L261), so an AZ failure (L286) fails over without data loss (L268); the backups — the automated snapshots and the point-in-time recovery (L304) — the recovery is the RTO/RPO story (L268, L374); and the extensions — including pgvector (L183) — the vector store inside Postgres (L183). The AI shape: the chat history (L166) and the conversation state (L165) in the relational tables (L268); the users and the tenants (L320) in the same database (L268); and the embeddings (L181) in the vector columns (L183) — the RAG (L280) reads the vectors with the SQL (L183). The managed trade: RDS runs the database — the patching, the backups, the failover (L268) — you write the SQL (L268)."

Think of RDS as the managed bank vault. You keep the valuables (the data, L268) in the vault (L268); the bank runs the vault — the security, the maintenance, the backups (L268). The vault has a second, mirrored chamber in another building (the multi-AZ standby, L261): if the first chamber fails, the second takes over instantly — nothing lost (L268). The bank photographs the vault's contents nightly (the backups, L304): any day's state is recoverable (L268). And the vault has a special drawer for the maps (the pgvector, L183): the embeddings (L181) sit in the vector columns (L183), searchable with the SQL (L268). The vault works because the bank runs it, the mirror protects it, and the photos recover it (L268).

   the vault (RDS, L268)
   ┌────────────────────────────────────────────────────────┐
   │ the instance (L268) — the compute + the storage        │
   │ the mirror (the multi-AZ, L261) — the standby          │
   │ the photos (the backups, L304) — the recovery          │
   │ the map drawer (the pgvector, L183) — the vectors      │
   └────────────────────────────────────────────────────────┘

The mental model is the vault: the instance, the mirror, the photos, and the map drawer (L268).

   the application (L268)
        │
        ▼
   ┌────────────────────── THE WRITE (L268) ───────────────────────────┐
   │  the primary instance in AZ-a (L268, L261)                       │
   │  the synchronous replication to the standby in AZ-b (L261)       │
   └──────────────────────────┬───────────────────────────────────────┘
                              ▼
   ┌────────────────────── THE FAILURE (L286) ────────────────────────┐
   │  AZ-a fails (L286) → the failover to AZ-b (L268)                 │
   │  the standby becomes the primary — no data loss (L268)           │
   └──────────────────────────┬───────────────────────────────────────┘
                              ▼
   ┌────────────────────── THE RECOVERY (L304) ───────────────────────┐
   │  the snapshots + the point-in-time recovery (L268)               │
   │  the RTO/RPO story (L374)                                        │
   └──────────────────────────────────────────────────────────────────┘

The flow is the data's life: write → replicate → failover → recover (L268).

• The instance (L268). The compute and the storage — the instance class and the allocated storage (L268). The sizing is the workload's match (L268): the IOPS (L268) for the throughput (L333).
• The multi-AZ (L261). The synchronous standby in another AZ (L261): the writes replicate synchronously (L268) — an AZ failure (L286) fails over without data loss (L268). The multi-AZ is the availability (L286).
• The backups (L304). The automated snapshots and the point-in-time recovery (L268): the database restores to any point in the retention window (L268) — the recovery (L304) is the RTO/RPO story (L374).
• The pgvector (L183). The extension that adds the vector type (L183): the embeddings (L181) stored in the columns (L183), searched with the SQL (L183). The RAG (L280) reads the vectors with the same database (L268).
• The managed trade (L268). RDS runs the database (L268): the patching, the backups, the failover (L268) — you write the SQL (L268).

• A production AI SaaS (L357). The users and the tenants (L320) in the relational tables (L268), the multi-AZ on (L261), the backups (L304) on.
• A RAG platform (L280). The pgvector (L183) in the same Postgres (L268): the chunks' embeddings (L181) in the vector columns (L183), the retrieval with the SQL (L189).
• A chat product (L166). The conversation history (L166) in the tables (L268), the state (L165) read and written by the Lambda (L266).
• A multi-tenant backend (L320). The tenant column and the row-level security (L320) in the managed Postgres (L268).
• Anything with data (L268). The relational data lives in RDS (L268) — the managed Postgres (L268).

The through-line: the managed Postgres is the data's home — sized, mirrored, backed up, and vector-ready (L268).

Say it in four moves:

1. The instance. "The managed compute and storage — the patching, the backups, the failover handled (L268)."
2. The multi-AZ. "The synchronous standby in another AZ (L261) — the failover without data loss (L268)."
3. The backups. "The snapshots and the point-in-time recovery (L304)."
4. The pgvector. "The vector store inside Postgres (L183) — the RAG reads it with the SQL (L268)."

• The multi-AZ is the availability's floor (L261). The synchronous standby (L268) — the AZ failure (L286) absorbed (L268) — the availability (L286) starts with the database (L268).
• The backups are the recovery's contract (L304). The RTO/RPO (L374) is the backup's design (L268): the snapshot frequency and the retention (L268) are the recovery contract (L304).
• The pgvector is the single-store move (L183). The vectors in the same Postgres (L183) — the relational data and the embeddings (L181) together (L268) — the operational simplicity (L268) over the separate vector DB (L182).
• The instance sizing is the cost (L285). The class and the storage (L268) — the IOPS (L268) is the bill's line (L285).
• The connection pooling is the scale lever (L268). The Lambda (L266) scale (L266) needs the pooled connections (L268) — the PgBouncer or the RDS Proxy (L268) between the functions and the database (L268).

• The single-AZ database (L268). No standby (L261) — the AZ failure (L286) is the data loss (L268).
• The backups off (L268). The snapshots disabled (L268) — the corruption (L304) unrecoverable (L268).
• The vectors in a separate store (L182). The separate vector DB (L182) for the small scale (L268) — the pgvector (L183) in the Postgres (L268) is the simple move (L268).
• The connection exhaustion (L268). The Lambda (L266) scale (L266) opening the connections (L268) — the RDS Proxy (L268) needed (L268).
• The giant instance (L268). The over-provisioned class (L268) — the cost (L285) without the need (L268).

• Turn on the multi-AZ (L261) — the failover without the data loss (L268).
• Turn on the backups (L304) — the point-in-time recovery (L268).
• Use the pgvector for the RAG (L183) — the vectors with the SQL (L268).
• Pool the connections (L268) — the RDS Proxy for the Lambda scale (L266).
• Size the instance to the workload (L268) — the IOPS (L268) and the cost (L285).

Q: Walk me through RDS.

A: The managed relational database (L268). The instance — the compute and the storage (L268). The multi-AZ — the synchronous standby in another AZ (L261). The backups — the snapshots and the point-in-time recovery (L304). And the extensions — including pgvector (L183), the vector store inside Postgres (L268).

Q: How do you run Postgres in production?

A: On RDS (L268). The multi-AZ for the availability (L261) — the failover without the data loss (L268). The automated backups (L304) — the point-in-time recovery (L268). The connection pooling (L268) — the RDS Proxy for the Lambda scale (L266). And the sizing to the workload (L268) — the instance class and the IOPS (L268).

Q: Where does pgvector live in production?

A: In the Postgres on RDS (L268). The pgvector extension (L183) adds the vector type (L183): the embeddings (L181) stored in the columns (L183), the retrieval with the SQL (L189). For the small and medium scale, the single Postgres (L268) is the simple move — the separate vector DB (L182) is the scale's later step (L268).

Q: What's the multi-AZ?

A: The synchronous standby (L268): the writes replicate to the standby in another AZ (L261) before the commit returns (L268). An AZ failure (L286) triggers the failover (L268) — the standby becomes the primary, and no committed data is lost (L268). The multi-AZ is the availability's floor (L261).

• What's the instance (L268)?
• What's the multi-AZ (L261)?
• What's the point-in-time recovery (L304)?
• Where does pgvector live (L183)?
• What's the connection pooling for (L268)?

The senior read: the managed premium buys the ops — the patching, the backups, the failover (L268).

// The data home (L268) — the managed Postgres (L268).
// THE INSTANCE (L268) — the compute and the storage (L268).
const rds = {
  engine: 'postgres',                     // the Postgres (L268)
  class: 'db.r6g.large',                  // the sizing (L268) — the cost (L285)
  storage: { size: 500, iops: 3000 },     // the IOPS for the throughput (L333)

  // THE MULTI-AZ (L261) — the synchronous standby (L268).
  multiAz: true,                          // the failover without the data loss (L268)

  // THE BACKUPS (L304) — the point-in-time recovery (L268).
  backups: { retention: 30, pitr: true }, // the RTO/RPO contract (L374)

  // THE PGVECTOR (L183) — the vector store inside Postgres (L268).
  extensions: ['vector'],                 // the embeddings' home (L181)
};

// THE RETRIEVAL (L183, L189) — the SQL against the vectors (L268).
//   SELECT id, 1 - (embedding <=> $1) AS score
//   FROM chunks
//   WHERE tenant_id = $2
//   ORDER BY embedding <=> $1
//   LIMIT 20;

What the reader must SEE — the data home, declared:

  engine postgres + vector → the managed Postgres + the pgvector (L268, L183)
  multiAz: true            → the synchronous standby (L261, L268)
  backups: retention + pitr → the point-in-time recovery (L304)
  the SQL with <=>         → the vector search (L183, L189)

  Sized, mirrored, backed up, and vector-ready (L268).

• The multi-AZ costs a write's latency (L268). The synchronous replication (L268) adds the round-trip to the standby (L268) — the availability (L286) for the write latency (L151).
• The IOPS is the throughput (L268). The provisioned IOPS (L268) — the throughput (L333) is the storage's design (L268).
• The connection pooling is the scale (L268). The RDS Proxy (L268) — the Lambda's (L266) many connections multiplexed (L268).
• The pgvector is the retrieval's speed (L183). The HNSW index (L183) on the vector columns (L183) — the retrieval (L189) stays fast at scale (L268).

• RDS & PostgreSQL on AWS = the managed Postgres (L268): the instance, the multi-AZ, the backups, the pgvector.
• The instance: the compute and the storage (L268).
• The multi-AZ: the synchronous standby (L261) — the failover without the data loss.
• The backups: the snapshots + the point-in-time recovery (L304).
• The pgvector: the vector store inside Postgres (L183) — the RAG reads it with the SQL (L189).

RDS & POSTGRESQL ON AWS = the managed Postgres — the data's home

THE INSTANCE (L268)
  the class + the storage + the IOPS — the sizing (L285)
  the patching, the backups, the failover — managed (L268)

THE MULTI-AZ (L261)
  the synchronous standby in another AZ (L268)
  the failover without the data loss (L268) — the availability (L286)

THE BACKUPS (L304)
  the automated snapshots (L268)
  the point-in-time recovery (L268) — the RTO/RPO contract (L374)

THE PGVECTOR (L183)
  the vector type inside Postgres (L183)
  the embeddings (L181) + the HNSW index (L183)
  the retrieval with the SQL (L189)

THE AI SHAPE (L268)
  the chat history (L166) · the users and the tenants (L320)
  the vectors (L183) — one database (L268)

INTERVIEW, 4 MOVES
  1 instance "the managed compute + storage (L268)"
  2 multi-AZ "the synchronous standby — the failover (L261)"
  3 backups  "the snapshots + the point-in-time recovery (L304)"
  4 pgvector "the vectors inside Postgres (L183)"

You now hold the data home: the instance, the multi-AZ, the backups, and the pgvector — with the vectors sitting next to the relational data. The backend has a database — and it's mirrored, backed up, and vector-ready (L268).

Next: the managed Redis — ElastiCache (L269).