Backend Validation (memledger v2.0.0)

memledger v2.0.0 ships with three production-quality storage backends. Each one was validated end-to-end against a real Amazon EKS cluster (<your-cluster-name>, us-west-2) running the kagent agentic example (triage / eks-ops / compliance). The validation includes the eval pipeline itself — the Tier 2 RAGAS judge round-trips through the live backend on each smoke run. DynamoDB and multi-backend composition land in v2.1.

The transcripts below come from kubectl Jobs that run inside the cluster, using the agent's IRSA-bound service account — i.e. the same identity the production agent uses. They are not curated highlights; they are the unedited stdout of the smoke runs.

Backend	Auth	Vector search	Hybrid search	Status
Postgres + pgvector (OSS)	password	✅	n/a	PASS
Aurora PostgreSQL + pgvector	IAM (rds-db:connect)	✅	n/a	PASS
Amazon OpenSearch	SigV4 (IRSA)	✅	✅ (vector + BM25)	PASS

Each run performs the same shape:

1. add() × 3 — episodic, semantic, procedural records with a derived_from chain (triage → eks-ops → compliance).
2. search() — semantic recall using Bedrock Titan v2 embeddings.
3. search_hybrid() (OpenSearch only) — vector + BM25.
4. Field round-trip assertion — confirms v2 governance fields (agent_id, confidence, derived_from) survive write/read.
5. delete() × 3 — clean teardown.

Postgres + pgvector (OSS)

In-cluster memledger-pgvector StatefulSet, password auth. This is the quickstart path documented in k8s-oss-recipe.

Smoke test transcript — postgres-pgvector-smoke-2026-05-24.log ✅ PASSED

OK: connected to backend=pgvector
OK: added 3 records: 03951cfb, 8c1b1a95, 4138869f
OK: search returned 3 hits
   - 8c1b1a95 type=semantic conf=0.7 agent=eks-ops-agent
   - 4138869f type=procedural conf=0.8 agent=compliance-agent
   - 03951cfb type=episodic conf=0.9 agent=triage-agent
OK: v2 fields round-tripped — agent_id=eks-ops-agent, confidence=0.7
OK: cleanup done
SMOKE TEST PASSED

Full log

Aurora PostgreSQL with IAM auth

Aurora cluster <your-aurora-cluster-id>, no password — the agent's IRSA role <your-irsa-role> mints a short-lived rds-db:connect token via boto3 on each connection. This is the recommended AWS-native path documented in kagent-on-eks.

Smoke test transcript — aurora-iam-smoke-2026-05-26.log ✅ PASSED

OK: connected to Aurora via IAM auth — backend=pgvector
OK: added 3 records: 49f13c8c, 7fd19232, 5b79e7b3
OK: search returned 3 hits
OK: v2 fields round-tripped — agent_id=eks-ops-agent, confidence=0.70
OK: cleanup done
AURORA IAM SMOKE TEST PASSED

Full log

The IAM-auth path means no Postgres password ever touches the agent pod, the Helm values, the build script, or any secret store. The backend resolves the host from the DSN, mints a token via the local boto3 session, and substitutes it for the password just before connecting. Tokens expire in 15 minutes, so connection pools refresh naturally.

Amazon OpenSearch with SigV4

OpenSearch domain <your-opensearch-domain> (single-AZ t3.small.search for the smoke run), HTTPS-only, encryption-at-rest + node-to-node TLS, access policy scoped to the agent's IRSA role. memledger-core's OpenSearch backend signs every request with SigV4 using the IRSA-injected AWS credentials.

Smoke test transcript — opensearch-sigv4-smoke-2026-05-26.log ✅ PASSED

OK: connected to OpenSearch via SigV4 — backend=opensearch
OK: added 3 records: 55f8d709, c80fe457, 295571ee
OK: search returned 3 hits
OK: v2 fields round-tripped — agent_id=eks-ops-agent, confidence=0.70
OK: hybrid search returned 3 hits
OK: cleanup done
OPENSEARCH SMOKE TEST PASSED

Full log

The OpenSearch backend is the only one that supports search_hybrid() (vector + BM25 in a single query). For agents that need lexical recall on top of semantic recall — e.g. exact error-code lookup alongside "things that look like this" — OpenSearch is the right choice.

Reproducing

The smoke scripts and Job specs are versioned in the amazon-eks-machine-learning-with-terraform-and-kubeflow repository (memory-integration branch), under examples/agentic/eks-ops-agent/. To reproduce, you need:

• An EKS cluster with kagent installed and the agentic example running.
• The agent IRSA role with rds-db:connect (Aurora) or es:ESHttp* (OpenSearch) policies attached to the relevant resources.
• A Bedrock-enabled region (the embedder uses Titan v2).

The full smoke runs take under a minute each; the only slow step is provisioning the OpenSearch domain (~7 minutes for t3.small.search).