pgvector

pgvector, sıradan bir PostgreSQL veritabanını yetenekli bir vektör deposuna dönüştüren açık kaynaklı bir uzantıdır; bir `vector` sütun tipi, mesafe operatörleri (Euclidean için `<->`, cosine için `<=>`, inner product için `<#>`) ve hızlı yaklaşık en yakın komşu araması için indeks tipleri (IVFFlat ve HNSW) ekler. AI/SaaS kuran ekipler için neden önemli: ekiplerin ürüne ikinci bir veritabanı sistemi eklemeden semantik arama veya RAG retrieval'i eklemesine olanak tanır. Çoğu SaaS backend'i zaten çekirdek ilişkisel verileri (kullanıcılar, abonelikler, siparişler) için Postgres çalıştırıyor; pgvector, embedding'lerin aynı veritabanında, hatta aynı tabloda, tanımladıkları satırların hemen yanında yaşayabileceği anlamına gelir — düz bir SQL `JOIN` ile birleştirilir, düz bir `WHERE` cümlesiyle filtrelenir ve geri kalan her şeyle aynı yedekleme, replikasyon ve transaksiyonel garantiler tarafından kapsanır. Bu operasyonel basitlik, pgvector benimsenmesinin 2024-2026 arasında patlamasının başlıca nedenlerinden biridir: bir hareketli parça daha az, bir tedarikçi faturası daha az, vektör deposunu doğruluk kaynağıyla tutarlı tutmak için bir veri senkronizasyon işi daha az. Nasıl çalışır: `CREATE EXTENSION vector;`den sonra, bir tabloya `embedding vector(1536)` gibi bir sütun eklersiniz, uygulamanız üzerinden doldurursunuz (bir embedding API'si çağırın, satırı `UPDATE` edin) ve satır sayıları birkaç on binin üzerine çıktığında hızlı yaklaşık arama için bir indeks inşa edersiniz — `CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);` (bunun altında, sıralı bir tarama genellikle yeterince hızlı ve daha basittir). Sorgular sıradan SQL gibi görünür: `SELECT id, body FROM articles ORDER BY embedding <=> $1 LIMIT 5;` bir sorgu vektörüne cosine mesafesine göre en yakın 5 komşuyu döndürür. Sadece Postgres olduğu için, vektör benzerliğini ilişkisel filtreleme ve metadata filtrelemeyle tek bir sorguda birleştirebilirsiniz — ayrı bir filtre API'si yok, iki sistem arasında eventual-consistency gecikmesi yok. Özel vektör veritabanlarına karşı ödünleşimler: çok büyük ölçekte (yüksek sorgu verimiyle on milyonlarca vektör) veya özellikle vektör iş yükleri için ayarlanmış çoklu bölge replikasyonuna ihtiyacınız olduğunda, Pinecone veya Qdrant gibi amaca özel depolar hâlâ genellikle pgvector'dan daha iyi performans gösterir ve daha iyi ölçeklenir. Örnek üzerinden: bir proje yönetimi SaaS'ı bir "AI arama" özelliği ekliyor. Pinecone kurmak yerine, mevcut `tasks` tablolarına `embedding vector(1536)` ekliyorlar, embedding API'sini çağıran bir toplu iş ile geriye doğru dolduruyorlar ve bir HNSW indeksi inşa ediyorlar. Arama endpoint'i şu hale geliyor: `SELECT * FROM tasks WHERE workspace_id = $1 ORDER BY embedding <=> $2 LIMIT 10;` — mevcut satır düzeyi kiracı izolasyonuna ücretsiz olarak saygı gösteren, tek bir migration ve tek bir endpoint'te gönderilen semantik arama.