Running transactional traffic and vector similarity search on the same PostgreSQL cluster is convenient, cheap, and quietly sets two workloads against each other. What to plan for before it hurts.
Start a conversationIt starts sensibly. There is already an Aurora PostgreSQL cluster holding application state. A retrieval feature is needed. pgvector installs with a single CREATE EXTENSION, needs no parameter group change, and requires no new infrastructure, no new vendor and no new bill.
So the embeddings go in the existing cluster. Reasonable, and often correct.
What follows is a list of things worth knowing before the decision becomes expensive to reverse.
Transactional traffic is short, indexed, highly concurrent, and touches a small number of rows. It rewards a large buffer cache holding hot pages, fast commit paths, and a lot of small connections.
Vector similarity search is long, scan-heavy, memory-hungry, and touches a great deal of data per query. It rewards large working memory per query and cares little about commit latency.
Run them together and they compete for the same buffer pool. Vector queries pull large index structures through memory and evict the pages the transactional workload depends on. The symptom is not slow retrieval. It is transactional latency degrading for no visible reason, at times that correlate with nothing in the application logs.
An HNSW index gives excellent query performance and is expensive to construct. Build time scales with row count and with the construction parameters, and it consumes substantial memory while running.
Two consequences most teams meet the hard way.
Vector search performs well when the index fits in memory and poorly when it does not. The fall-off is not gradual.
So the instance ends up sized for the vector index rather than for the transactional workload, which means paying for memory the OLTP side does not need in order to keep retrieval acceptable. That is a real cost, and it is the number that eventually motivates separation.
Transactional workloads want many short connections and pool well. Vector queries hold connections longer and use more memory each.
A single pool sized for one starves the other. Separate pools with separate limits, ideally separate database users so the behaviour is attributable in monitoring.
Put vector tables in their own schema. It costs nothing on day one and makes the eventual separation a migration rather than an archaeology exercise. It also keeps grants clean, which matters when the retrieval layer is consumed by something outside the application.
Directing vector queries at a replica keeps the writer free for transactional work and is far less disruptive than splitting the estate. Not a permanent answer at scale, but it buys a lot of time cheaply.
Aggregate database metrics hide this problem completely. Attribute load by user or by query pattern so the two workloads can be seen apart. Without that, the eviction problem looks like random latency.
Write down the condition that triggers separation, whether that is index size relative to memory, a p99 latency target on the transactional side, or a cost ceiling. Deciding it calmly in advance is better than deciding it during an incident.
Frequently. Modest corpus, moderate query volume, and a transactional workload with headroom, and the operational simplicity of one cluster beats the theoretical purity of two.
The mistake is not choosing one cluster. It is choosing one cluster without knowing what the second one would cost, or when it would be needed.
If any of the above matches a problem in front of you, the fastest way in is a fixed-scope assessment. Two to three weeks, written findings, yours to keep either way.