Quand on construit un pipeline RAG (Retrieval-Augmented Generation), la question du stockage des embeddings se pose rapidement. On a vu dans un pr\u00e9c\u00e9dent article comment d\u00e9ployer Qdrant, une base vectorielle d\u00e9di\u00e9e. Mais si votre infrastructure repose d\u00e9j\u00e0 sur PostgreSQL, ce qui est le cas pour CKAN, Keycloak, Nextcloud, Gitea, Drupal et tant d’autres applications, il existe une alternative \u00e9l\u00e9gante : pgvector<\/strong>, une extension open source qui ajoute nativement le support des vecteurs et de la recherche par similarit\u00e9 directement dans PostgreSQL. Pas de service suppl\u00e9mentaire \u00e0 d\u00e9ployer, pas de synchronisation \u00e0 maintenir, pas de port r\u00e9seau \u00e0 ouvrir.<\/p>\n\n\n\n Les bases vectorielles sp\u00e9cialis\u00e9es (Qdrant, Milvus, Weaviate, Pinecone) offrent des performances remarquables sur de tr\u00e8s grands volumes : des centaines de millions de vecteurs. Mais la majorit\u00e9 des cas d’usage en production ne n\u00e9cessitent pas cette \u00e9chelle. Pour un portail open data avec quelques dizaines de milliers de documents, un assistant interne sur une base documentaire de 50 000 pages, ou un moteur de recherche s\u00e9mantique sur les m\u00e9tadonn\u00e9es CKAN, pgvector suffit largement et pr\u00e9sente des avantages d\u00e9cisifs.<\/p>\n\n\n\n Premier avantage : la simplicit\u00e9 op\u00e9rationnelle<\/strong>. pgvector vit dans votre PostgreSQL<\/a> existant. Pas de conteneur suppl\u00e9mentaire, pas de backup s\u00e9par\u00e9, pas de monitoring d\u00e9di\u00e9. Vos proc\u00e9dures de sauvegarde (BorgBackup<\/a>), de tuning et de haute disponibilit\u00e9 (r\u00e9plication, patroni) couvrent automatiquement les donn\u00e9es vectorielles. Deuxi\u00e8me avantage : la coh\u00e9rence transactionnelle<\/strong>. Vos embeddings et vos m\u00e9tadonn\u00e9es structur\u00e9es vivent dans la m\u00eame base, la m\u00eame transaction. Pas de risque de d\u00e9synchronisation entre un document mis \u00e0 jour dans PostgreSQL et son embedding encore pr\u00e9sent dans une base vectorielle externe. pgvector s’installe comme n’importe quelle extension PostgreSQL. Sur une instance Docker, il suffit d’utiliser l’image officielle Une fois l’extension charg\u00e9e, la configuration se fait en quelques lignes SQL :<\/p>\n\n\n\n Le type pgvector propose deux algorithmes d’indexation. HNSW<\/strong> (Hierarchical Navigable Small World) est le choix par d\u00e9faut recommand\u00e9 : il offre les meilleures performances en lecture avec un temps de construction raisonnable. Le param\u00e8tre Pour la plupart des cas d’usage, HNSW avec les param\u00e8tres par d\u00e9faut offre un excellent rappel (>95 %) avec des temps de requ\u00eate inf\u00e9rieurs \u00e0 10 ms sur des collections de quelques centaines de milliers de vecteurs.<\/p>\n\n\n\n L’int\u00e9gration de pgvector dans un pipeline RAG existant est directe. Voici le flux typique avec une stack enti\u00e8rement open source :<\/p>\n\n\n\n Phase d’ingestion :<\/strong> un script Python (ou un workflow n8n) r\u00e9cup\u00e8re les documents depuis CKAN, Nextcloud ou un r\u00e9pertoire local. Chaque document est d\u00e9coup\u00e9 en chunks (paragraphes ou sections), puis chaque chunk est envoy\u00e9 \u00e0 Ollama pour g\u00e9n\u00e9rer son embedding via un mod\u00e8le comme Phase de requ\u00eate :<\/strong> quand un utilisateur pose une question, son texte est transform\u00e9 en embedding par le m\u00eame mod\u00e8le, puis pgvector cherche les chunks les plus proches par distance cosinus. Les r\u00e9sultats sont inject\u00e9s comme contexte dans le prompt envoy\u00e9 au LLM (Ollama, vLLM).<\/p>\n\n\n\n L’op\u00e9rateur pgvector g\u00e8re confortablement des collections de quelques centaines de milliers \u00e0 quelques millions de vecteurs sur un serveur modeste (16 Go de RAM, SSD). Au-del\u00e0 de 5 \u00e0 10 millions de vecteurs en dimension 1536, les performances commencent \u00e0 se d\u00e9grader et une base vectorielle d\u00e9di\u00e9e comme Qdrant devient pertinente. Les param\u00e8tres cl\u00e9s \u00e0 surveiller sont le Le choix entre pgvector et une base vectorielle d\u00e9di\u00e9e se r\u00e9sume souvent \u00e0 une question de volume et de complexit\u00e9 op\u00e9rationnelle. pgvector est le bon choix quand vous avez d\u00e9j\u00e0 PostgreSQL dans votre stack, que votre collection ne d\u00e9passe pas quelques millions de vecteurs, et que vous valorisez la simplicit\u00e9 de maintenance et la coh\u00e9rence transactionnelle. Qdrant (ou Milvus, Weaviate) devient pertinent quand vous g\u00e9rez des dizaines de millions de vecteurs, que vous avez besoin de fonctionnalit\u00e9s avanc\u00e9es comme le multi-tenancy natif, le filtrage par payload optimis\u00e9, ou la r\u00e9plication distribu\u00e9e.<\/p>\n\n\n\n En pratique, pgvector est souvent le bon point de d\u00e9part. Il est plus simple \u00e0 d\u00e9ployer, \u00e0 sauvegarder et \u00e0 monitorer. Et si les besoins \u00e9voluent, la migration vers une base d\u00e9di\u00e9e reste possible \u2014 les embeddings sont les m\u00eames, seul le stockage change.<\/p>\n\n\n\n Il suffit de remplacer l’image PostgreSQL standard par pgvector transforme PostgreSQL en base vectorielle sans ajouter de complexit\u00e9 \u00e0 votre infrastructure. Pour la majorit\u00e9 des projets RAG auto-h\u00e9berg\u00e9s : assistant sur donn\u00e9es ouvertes, moteur de recherche s\u00e9mantique interne, indexation documentaire, c’est le chemin le plus court entre vos documents et un LLM capable de les exploiter. Combin\u00e9 avec Ollama<\/a> pour les embeddings et l’inf\u00e9rence, n8n<\/a> pour l’orchestration et Langfuse<\/a> pour l’observabilit\u00e9, il compl\u00e8te une stack RAG 100 % open source qui tient dans un seul <\/p>","protected":false},"excerpt":{"rendered":" pgvector : la recherche vectorielle dans PostgreSQL pour un RAG sans brique suppl\u00e9mentaire Quand on construit un pipeline RAG (Retrieval-Augmented Generation), la question du stockage des embeddings se pose rapidement. On a vu dans un pr\u00e9c\u00e9dent article comment d\u00e9ployer Qdrant, une base vectorielle d\u00e9di\u00e9e. Mais si votre infrastructure repose d\u00e9j\u00e0 sur PostgreSQL, ce qui est le […]<\/p>\n","protected":false},"author":1,"featured_media":2240,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"","ocean_second_sidebar":"","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"","ocean_custom_header_template":"","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"","ocean_menu_typo_font_family":"","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"","osh_disable_topbar_sticky":"default","osh_disable_header_sticky":"default","osh_sticky_header_style":"default","osh_sticky_header_effect":"","osh_custom_sticky_logo":0,"osh_custom_retina_sticky_logo":0,"osh_custom_sticky_logo_height":0,"osh_background_color":"","osh_links_color":"","osh_links_hover_color":"","osh_links_active_color":"","osh_links_bg_color":"","osh_links_hover_bg_color":"","osh_links_active_bg_color":"","osh_menu_social_links_color":"","osh_menu_social_hover_links_color":"","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"on","ocean_gallery_id":[],"footnotes":""},"categories":[16,18],"tags":[],"class_list":["post-2239","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-devops","entry","has-media"],"yoast_head":"\nPourquoi pgvector plut\u00f4t qu’une base vectorielle d\u00e9di\u00e9e<\/h3>\n\n\n\n
Troisi\u00e8me avantage : la possibilit\u00e9 de combiner recherche vectorielle et filtres SQL classiques dans une seule requ\u00eate, par exemple, chercher les documents les plus proches s\u00e9mantiquement parmi ceux publi\u00e9s apr\u00e8s une certaine date et appartenant \u00e0 une organisation donn\u00e9e.<\/p>\n\n\n\nInstallation et configuration<\/h3>\n\n\n\n
pgvector\/pgvector:pg16<\/code> (ou pg15, pg17 selon votre version). Si vous g\u00e9rez PostgreSQL directement sur le serveur, l’extension se compile depuis les sources en quelques commandes, ou s’installe via le gestionnaire de paquets sur les distributions courantes.<\/p>\n\n\n\n-- Activer l'extension\nCREATE EXTENSION IF NOT EXISTS vector;\n\n-- Cr\u00e9er une table avec une colonne vectorielle\nCREATE TABLE documents (\n id SERIAL PRIMARY KEY,\n title TEXT NOT NULL,\n content TEXT,\n source_url TEXT,\n organization TEXT,\n created_at TIMESTAMP DEFAULT NOW(),\n embedding vector(1536) -- dimension selon le mod\u00e8le d'embedding\n);\n\n-- Cr\u00e9er un index HNSW pour la recherche rapide\nCREATE INDEX ON documents\nUSING hnsw (embedding vector_cosine_ops)\nWITH (m = 16, ef_construction = 200);<\/code><\/pre>\n\n\n\nvector(1536)<\/code> stocke des vecteurs de dimension 1536 -, la dimension standard des embeddings d’OpenAI text-embedding-3-small ou de mod\u00e8les open source comme nomic-embed-text<\/code> servi par Ollama. pgvector supporte des dimensions allant jusqu’\u00e0 2000 (et au-del\u00e0 avec le type halfvec<\/code> en demi-pr\u00e9cision).<\/p>\n\n\n\nTypes d’index : HNSW vs IVFFlat<\/h3>\n\n\n\n
m<\/code> contr\u00f4le le nombre de connexions par n\u0153ud (16 est un bon d\u00e9faut), et ef_construction<\/code> la qualit\u00e9 de construction de l’index (200 offre un bon compromis). IVFFlat<\/strong> est plus rapide \u00e0 construire et consomme moins de m\u00e9moire, mais n\u00e9cessite un entra\u00eenement pr\u00e9alable sur les donn\u00e9es existantes, il convient mieux aux jeux de donn\u00e9es statiques de grande taille.<\/p>\n\n\n\nInt\u00e9gration dans un pipeline RAG avec Ollama<\/h3>\n\n\n\n
nomic-embed-text<\/code> ou mxbai-embed-large<\/code>. Le chunk et son embedding sont ins\u00e9r\u00e9s dans la table pgvector.<\/p>\n\n\n\nimport ollama\nimport psycopg2\n\n# G\u00e9n\u00e9rer l'embedding via Ollama\nresponse = ollama.embeddings(\n model=\"nomic-embed-text\",\n prompt=chunk_text\n)\nembedding = response[\"embedding\"]\n\n# Ins\u00e9rer dans PostgreSQL\/pgvector\ncur.execute(\"\"\"\n INSERT INTO documents (title, content, source_url, organization, embedding)\n VALUES (%s, %s, %s, %s, %s::vector)\n\"\"\", (title, chunk_text, url, org, str(embedding)))<\/code><\/pre>\n\n\n\n-- Recherche des 5 documents les plus proches\n-- avec filtre SQL classique sur l'organisation\nSELECT title, content, source_url,\n 1 - (embedding <=> query_embedding::vector) AS similarity\nFROM documents\nWHERE organization = 'ville-de-rennes'\nORDER BY embedding <=> query_embedding::vector\nLIMIT 5;<\/code><\/pre>\n\n\n\n<=><\/code> calcule la distance cosinus. pgvector supporte \u00e9galement la distance euclidienne (<-><\/code>) et le produit scalaire (<#><\/code>). La combinaison avec des clauses WHERE<\/code> SQL classiques est le point fort de cette approche : pas besoin de pr\u00e9-filtrer c\u00f4t\u00e9 applicatif.<\/p>\n\n\n\nPerformances et limites<\/h3>\n\n\n\n
maintenance_work_mem<\/code> (augmenter pour acc\u00e9l\u00e9rer la construction des index HNSW), le shared_buffers<\/code> (pour garder l’index en m\u00e9moire), et le ef_search<\/code> (ajustable par session pour arbitrer entre vitesse et rappel).<\/p>\n\n\n\n-- Augmenter la qualit\u00e9 de recherche pour une requ\u00eate pr\u00e9cise\nSET hnsw.ef_search = 200;\n\n-- Revenir au d\u00e9faut pour les requ\u00eates courantes\nSET hnsw.ef_search = 40;<\/code><\/pre>\n\n\n\nQuand choisir pgvector, quand choisir Qdrant<\/h3>\n\n\n\n
Docker Compose : ajouter pgvector \u00e0 sa stack existante<\/h3>\n\n\n\n
# docker-compose.yml \u2014 extrait\nservices:\n postgres:\n image: pgvector\/pgvector:pg16\n environment:\n POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n POSTGRES_DB: app\n volumes:\n - pgdata:\/var\/lib\/postgresql\/data\n ports:\n - \"5432:5432\"\n deploy:\n resources:\n limits:\n memory: 4G\n\nvolumes:\n pgdata:<\/code><\/pre>\n\n\n\npgvector\/pgvector:pg16<\/code>. L’image est bas\u00e9e sur l’image officielle PostgreSQL avec l’extension pr\u00e9-compil\u00e9e. Aucune autre modification n’est n\u00e9cessaire, vos bases, utilisateurs et donn\u00e9es existants restent intacts.<\/p>\n\n\n\nConclusion<\/h3>\n\n\n\n
docker-compose.yml<\/code>.<\/p>\n\n\n\n