Retrieval-augmented generation (RAG) has become the default architecture for building AI features on top of business data — and the part most teams underestimate is not the model, it’s the pipeline that keeps vectors in sync with the source of truth. If your embeddings are stale, search results drift, recommendations go quiet, and your chatbot starts answering from outdated facts. That is a data infrastructure problem, not a prompt problem.
New guidance from AWS on automating vector embedding generation in Amazon Aurora PostgreSQL with Amazon Bedrock lays out the options clearly: five patterns, each with different trade-offs between simplicity, latency, consistency, and operational cost. Here’s what matters for teams building production RAG systems — and what the trigger-based approach looks like in practice.
Why PostgreSQL Became the Default Home for Vectors
PostgreSQL with the pgvector extension has quietly become the default vector store for a large share of GenAI applications. The reasons are pragmatic: teams already run Postgres, already know how to back it up, secure it, and monitor it — and adding a 1,536-dimension vector column is a migration, not a new platform. As Nasscom’s analysis of which database suits generative AI applications notes, suitability depends less on hype and more on fit with existing workloads, operational maturity, and the ability to serve transactional and vector workloads from one system.
The pattern extends across clouds. Microsoft’s ecosystem has pushed hard on PostgreSQL as the backbone of GenAI apps on Azure AI, and AWS’s own guidance treats Aurora PostgreSQL as a first-class vector store. Even the debate over where AI should run — Oracle argues AI belongs where the data lives, while Postgres-native specialists like EDB push back — points in the same direction: the database layer is becoming the AI layer.
The Real Problem: Stale Embeddings
Standing up a vector store is the easy part. The hard part is keeping embeddings current. When a document is inserted or updated, its embedding must be regenerated — otherwise semantic search quietly returns outdated results. Doing this by hand or with one-off scripts does not survive contact with production.
AWS’s post walks through the general workflow: detect new or modified data, send content to an embedding model (Amazon Titan in their examples), receive the vector, and store it alongside the original row. The interesting part is the five ways to automate that loop.
Five Ways to Automate Embedding Generation
1. Database triggers with the aws_ml extension (synchronous). The simplest pattern: a trigger fires on INSERT or UPDATE, calls Bedrock directly from the database via aws_bedrock.invoke_model_get_embeddings, and writes the vector in the same transaction. Real-time consistency with minimal moving parts — but embedding calls extend transaction time, which means lock contention and timeout risk under load.
2. Lambda-orchestrated synchronous calls. The same trigger idea, but the work moves to a Lambda function via the aws_lambda extension. Better separation of duties, still in the write path.
3. Lambda-orchestrated asynchronous calls. The trigger hands off to an event-driven invocation and the write completes immediately. Database performance improves; consistency becomes eventual.
4. Queue-based batch processing with Amazon SQS. Embedding requests flow through a queue and are processed in batches. The best scalability and resilience for high-volume workloads — at the cost of more architecture to operate.
5. Scheduled updates with pg_cron. A periodic job regenerates embeddings for changed rows. Simple and cheap, and perfectly adequate when near-real-time freshness isn’t critical.
There is no universal winner. The right choice is a function of write volume, freshness requirements, and how much infrastructure your team can operate.
How the Trigger Approach Works
For teams that want a working starting point, the trigger pattern is the easiest to reason about. AWS’s example uses two tables: documents (content plus a processing status) and document_embeddings (the vector, linked by foreign key). A BEFORE INSERT OR UPDATE trigger calls a PL/pgSQL function that invokes Bedrock and upserts the result:
CREATE OR REPLACE FUNCTION generate_embedding(input_text TEXT)
RETURNS vector(1536) AS $$
DECLARE embedding_result vector(1536);
BEGIN
EXECUTE $embed$ SELECT aws_bedrock.invoke_model_get_embeddings(
model_id := 'amazon.titan-embed-text-v2:0',
content_type := 'application/json',
json_key := 'embedding',
model_input := json_build_object('inputText', $1)::text)$embed$
INTO embedding_result USING input_text;
RETURN embedding_result;
END; $$ LANGUAGE plpgsql;The pattern is small, explicit, and easy to debug — exactly what you want before scaling up to queues and async workers.
What to Watch Before You Build
AWS flags the design considerations that bite in production: Bedrock rate limits (throttling and batching may be required), token limits on embedding models (long fields need chunking strategies), cost per API call and Lambda invocation, latency versus consistency trade-offs, and database throughput during peak load. Synchronous approaches can measurably slow ingestion; asynchronous approaches buy performance with temporary inconsistency. Error handling and retry logic also get stronger as you move up the complexity ladder.
The Takeaway for Agencies
If you are building RAG features for clients — support assistants, knowledge bases, internal search — treat the embedding pipeline as product infrastructure, not glue code. Automating it keeps retrieval accurate, cuts manual upkeep, and makes the system survivable when a client’s dataset grows. The model gets the attention; the data layer earns the revenue.
Need help designing a data stack for AI features that actually stays accurate? Outdoor Tek builds and operates AI-powered marketing and customer-facing systems — get in touch.