Add a self-hosted PostgreSQL/pgvector semantic memory backend (PgvectorMemory)

[Nantha kumar (Nanduu24)]

Summary

Add a self-hosted, semantic PgvectorMemory backend to autogen-ext (autogen_ext.memory.pgvector), backed by PostgreSQL with the pgvector extension.

Motivation

autogen-ext/memory today ships chromadb, mem0, redis, and canvas, but none offers vector memory on a general-purpose SQL database the user already controls. Teams that run on PostgreSQL and need semantic agent memory on-premise, in air-gapped environments, or under data-residency constraints have no built-in option. pgvector is the standard way to add vector search to Postgres, so a PgvectorMemory closes that gap and complements the existing backends.

Proposed behavior

A PgvectorMemory(Memory, Component[PgvectorMemoryConfig]) that:

• add embeds a MemoryContent (TEXT / MARKDOWN / JSON) and stores it, with its vector, in a Postgres table (extension/table/HNSW index created on first use).
• query embeds the query and returns the nearest memories by cosine distance via a pgvector HNSW index, with an optional distance_threshold.
• update_context injects the relevant memories as a SystemMessage, matching the other backends.
• clear / close behave as expected.
• Embeds via a local SentenceTransformers model by default (configurable model_name), with an injectable embedding_function override.
• Ships as an optional extra: pip install "autogen-ext[pgvector]".

It follows the existing redis / chromadb component pattern (a serializable Component config), and the connection pool and embedder are both injectable, which keeps it unit-testable without a live database.

Willingness to contribute

Yes — I already have a complete implementation with unit tests (that run without a live DB) and I verified it end-to-end against a real PostgreSQL + pgvector instance. I'd like to contribute it; I can open the PR right away. Posting here first per the feature-suggestion process — happy to adjust the design based on feedback.