TL;DR

If you are running an Amazon Bedrock Knowledge Base backed by OpenSearch Serverless (AOSS), you are paying a ~$700/month floor before you ingest a single document. For most small and mid-sized RAG workloads, swapping AOSS for Aurora PostgreSQL Serverless v2 with the pgvector extension drops that floor to under $50/month a ~90% cost reduction; while remaining a fully supported, first-class vector store for Bedrock Knowledge Bases.

This post walks through the why, the math, the trade-offs, and the migration path, using a real production infrastructure as the reference implementation.

The problem: AOSS has a hard minimum bill

When you create a Bedrock Knowledge Base through the console or Terraform, AWS nudges you toward OpenSearch Serverless as the default vector store. That default is convenient, but it hides a pricing reality that is easy to miss in a proof of concept and painful in production.

OpenSearch Serverless bills on OpenSearch Compute Units (OCUs):

• 2 OCUs minimum for indexing
• 2 OCUs minimum for search
• Plus redundancy multipliers in production mode

That gives you a 4 OCU minimum for any non-dev collection. At the eu-west-1 on-demand rate of roughly $0.24 per OCU-hour: 4 OCU × $0.24/OCU-hr × 730 hr/month ≈ $700/month

That is the floor. Empty index. No traffic. No queries. Just for the collection to exist.

For a lean RAG use case — a documentation chatbot, an internal Q&A assistant, a support deflection bot; this dwarfs everything else in the stack. Bedrock model invocations, Lambda, API Gateway, and S3 combined often come in under $100/month. OpenSearch then accounts for 80–90% of the bill while doing very little work.

The reference workload

The numbers below come from a production AI infrastructure (Terraform, eu-west-1) with this shape:

In other words: a completely normal SMB-scale RAG workload. The kind OpenSearch Serverless is aggressively over-provisioned for.

Why Aurora Serverless v2 + pgvector is the right fit here

Amazon Bedrock Knowledge Bases officially supports Amazon Aurora PostgreSQL-Compatible as a vector store, alongside OpenSearch Serverless, Pinecone, MongoDB Atlas, and Redis Enterprise. This is not a hack or a workaround; it is a first-class, AWS-documented integration.

The ingredients:

• Aurora Serverless v2 scales compute in Aurora Capacity Units (ACUs) and, since late 2024, supports scaling to 0 ACUs when idle.
• pgvector is the standard PostgreSQL extension for vector similarity search, with ivfflat and hnsw index types.
• Bedrock Knowledge Base can use an Aurora cluster directly, provided the table, vector column, and HNSW index are pre-created according to the AWS spec.

For our Titan v2 / 1024-dimension / a-few-thousand-chunks profile, a min_capacity = 0 / max_capacity = 2 Aurora Serverless v2 cluster handles ingestion and retrieval comfortably.

Cost comparison

Using current eu-west-1 on-demand pricing as a representative baseline (always re-run the math for your region):

Yes — in round numbers, that is a 10–15× cost reduction on the vector store line, or roughly $600+/month saved per environment. Multiply that across dev / staging / prod and the annual savings get serious fast.

Where AOSS still wins

This is not a “pgvector beats OpenSearch” post. AOSS remains the right answer when:

• You need sub-100ms p99 at very high QPS with large indexes.
• Your corpus is tens of millions of vectors and growing.
• You want hybrid keyword + vector search with OpenSearch’s full text features.
• You need the neural plugins, rerankers, and semantic pipelines that ship with OpenSearch.

For everything below that ceiling which is most RAG workloads in the wild; Aurora + pgvector is plenty fast and dramatically cheaper.

Migration outline

The migration is straightforward but has a few gotchas worth knowing up front.

1. Provision Aurora Serverless v2 with pgvector

resource "aws_rds_cluster" "kb" {
  engine                      = "aurora-postgresql"
  engine_mode                 = "provisioned"
  engine_version              = "15.5"
  database_name               = "kb"
  master_username             = "kb_admin"
  manage_master_user_password = true
  storage_encrypted           = true

  serverlessv2_scaling_configuration {
    min_capacity = 0      # scale-to-zero when idle
    max_capacity = 2
  }
}

resource "aws_rds_cluster_instance" "kb" {
  cluster_identifier = aws_rds_cluster.kb.id
  instance_class     = "db.serverless"
  engine             = aws_rds_cluster.kb.engine
  engine_version     = aws_rds_cluster.kb.engine_version
}

Then, on first connect:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE SCHEMA bedrock_integration;

CREATE TABLE bedrock_integration.bedrock_kb (
  id        uuid PRIMARY KEY,
  embedding vector(1024),
  chunks    text,
  metadata  json
);

CREATE INDEX ON bedrock_integration.bedrock_kb
  USING hnsw (embedding vector_cosine_ops);

CREATE INDEX ON bedrock_integration.bedrock_kb
  USING gin (to_tsvector('simple', chunks));

The column names and types (id, embedding, chunks, metadata) are required by Bedrock Knowledge Base; follow the AWS spec exactly.

2. Store the DB credentials in Secrets Manager

Bedrock KB reads database credentials from a Secrets Manager secret. If you use manage_master_user_password = true on the cluster, Aurora manages that secret for you just hand its ARN to the Knowledge Base configuration.

3. Point the Knowledge Base at Aurora instead of OpenSearch

In Terraform, swap the storage_configuration block:

storage_configuration {
  type = "RDS"
  rds_configuration {
    resource_arn           = aws_rds_cluster.kb.arn
    credentials_secret_arn = aws_rds_cluster.kb.master_user_secret[0].secret_arn
    database_name          = aws_rds_cluster.kb.database_name
    table_name             = "bedrock_integration.bedrock_kb"
    field_mapping {
      primary_key_field = "id"
      vector_field      = "embedding"
      text_field        = "chunks"
      metadata_field    = "metadata"
    }
  }
}

Everything upstream the S3 data source, the chunking strategy, the embedding model, the ingestion Lambda stays identical.

4. Re-ingest

Trigger a full ingestion job against the new Knowledge Base. Embeddings are re-computed from S3, so there is no data migration step from AOSS to Aurora, you rebuild the index from the source of truth.

5. Decommission the OpenSearch collection

Only after you have validated answers on the new KB. Keep the old collection around for a week or two; the cost of that overlap is trivial compared to one bad rollback.

Production caveats

A few things worth flagging before you ship this:

• Cold starts. Aurora Serverless v2 scale-to-zero resumes in roughly 10–15 seconds. If your chatbot has strict p99 SLAs, set min_capacity = 0.5 instead of 0; you still save ~85% vs. AOSS.
• HNSW tuning. Defaults are fine to start. If recall degrades at scale, tune m and ef_construction on the index, and hnsw.ef_search at query time.
• Backups. Aurora backups and snapshots are your responsibility now. OpenSearch Serverless snapshotting was automatic.
• VPC. Bedrock KB to Aurora runs over the VPC. Make sure subnets, security groups, and the Bedrock service role are wired up correctly. This is the #1 source of “it works in the console but fails on ingestion” bugs.
• Scaling ceiling. At ~1M+ vectors with sustained high QPS, re-evaluate. pgvector + HNSW is excellent, but AOSS and purpose-built vector DBs do pull ahead in that regime.

Bottom line

For the vast majority of Bedrock-powered RAG applications, documentation bots, knowledge assistants, support automation, internal Q&A OpenSearch Serverless is over-engineered and overpriced. Aurora Serverless v2 with pgvector is a supported, production-grade alternative that costs an order of magnitude less at small-to-medium scale, with migration measured in hours rather than weeks.

If your FinOps team has been asking why a “lightweight chatbot” costs $800+/month on AWS, the answer is almost certainly sitting in your OpenSearch bill line. Swap the vector store, keep everything else, and reclaim the budget.

Written from production experience running Bedrock Knowledge Bases in eu-west-1. Prices and configurations reflect AWS as of April 2026 — always validate current pricing and service limits for your region before committing to a migration.