turbopuffer v3'te vector index'i ikincilleştiriyor, Postgres vs vector DB tartışmasını yeniden alevlendiriyor

turbopuffer vector index'i ikincilleştiriyor

turbopuffer, Cursor ve Notion'ın arama katmanı, 30 Eylül'de "RIP, vector database" başlıklı bir blog yazısıyla motorunda yapısal bir yenileme duyurdu. Sürüm 3'te belgeler kararlı bir belge kimliğiyle anahtarlanacak ve approximate nearest neighbour index, birincil veri yapısı olmaktan çıkıp ikincil bir index haline gelecek. Vektör araması çalışmaya devam edecek; sadece depolama katmanının organizasyon ilkesi olmaktan çıkacak.

Şirketin bu iddiayı destekleyecek iş yükü var. jamilxt'nin dev.to analizine göre Cursor, turbopuffer üzerinde milyonlarca kod tabanında milyarlarca vektör çalıştırıyor; Notion ise milyonlarca namespace'te 10 milyardan fazla vektör sunuyor. turbopuffer, 100 milyar üzeri vektör içeren tek index'ler, 200 ms p99 okuma ve saniyede 1.000'den fazla sorgu iddia ediyor.

Sebep write amplification

turbopuffer'ın mevcut düzeni, bir belgenin tüm içeriğini vektörünün cluster adresiyle anahtarlayarak saklıyor. Clustering index yeniden dengelendiğinde — bu rutin insert ve update'lerde gerçekleşiyor — belgenin tamamı ve ona işaret eden tüm inverted index girdileri de taşınıyor. turbopuffer, tek bir vektör güncellemesinin yüzlerce attribute'u sürükleyebildiğini söylüyor. dev.to yazısı ayrıca sorgu planlarının 100–200 belgelik cluster boyutlu bloklara kilitlendiğini, DuckDB'deki 2.048 satırlık batch'lerle ve ClickHouse'daki kabaca 65.000 satıra kadar olan batch'lerle karşılaştırıyor.

Duyuruyu iki uyarı gölgeliyor. turbopuffer, v3'ün şu anda henüz ayarlanmaya yeni başlanmış ciddi bir performans gerilemesi olduğunu kabul ediyor; yine de Ekim başı itibarıyla tüm CI testlerinin yeşil geçtiğini bildiriyor. Ve ekonomi değişmiyor: object storage gerçeğin kaynağı olmaya devam ediyor; dev.to'da aktarılan rakamlara göre, SSD cache ile aylık TB başına yaklaşık 70 dolarlık orijinal fiyatlandırma, cache-artı-SSD kullanan mevcut oyuncuların kabaca 1.600 dolarına karşı duruyor.

Yazının gündeme getirdiği Postgres sorusu

turbopuffer'ın blog yazılarına ve bir Hacker News başlığına dayanan dev.to yazısı, duyurunun ekipleri sık atladıkları bir soruyu yeniden sormaya itmesi gerektiğini savunuyor: Postgres her şeyden beri yeterli miydi? Yazar tekrarlayan bir örüntü anlatıyor — bir ekip bir benchmark okur, Postgres'in embedding'lerini sunamayacağı sonucuna varır, özel bir vector veritabanına göç eder ve elinde ikinci bir veritabanı, bir sync job, yeni bir hata modu ve hiçbir kullanıcının fark etmediği bir hızlanma kalır.

Ham rakamlarla, Supabase pgvector'ı 16 çekirdekli, 256 GB'lık bir sunucuda bir milyonluk vektör veri seti üzerinde yaklaşık 1.800 QPS ve 0,91 accuracy@10 ile benchmark etti. Özel motor karşı argümanı ise kabaca 100 milyon vektörün ötesinde amaç-built motorların latency ve bellekte kazandığı: HNSW graph'ları belleği çok tüketir ve Postgres'in vektör iş yükleri için yerleşik sharding'i yoktur. turbopuffer'ın kendi verisi ise depolama ekonomisine odaklanıyor — bir milyonluk 768 boyutlu vektör yaklaşık 3 GB'a sığıyor, cold sorgular object storage'dan yaklaşık 444 ms p90 ile dönerken warm olanlar yaklaşık 10 ms p90 ile dönüyor; yani tiering, her şeyi RAM'de tutmaya kıyasla çok daha düşük maliyetle kazanıyor.

Sorgu şekli çoğu zaman kararı veriyor

dev.to yazısına göre en güçlü Postgres vakası gerçek sorguların şekli: tenant filtreleri, join'ler, yetkilendirme ve ranking ile birleşen benzerlik araması. Postgres'te bu tek bir transaction içinde tek bir SQL ifadesidir; özel bir vector motorundaysa ilişkisel veriye join genellikle uygulama kodunda ikinci bir tur olarak gerçekleşir. Yoğun trafikli bir workspace'e kapsamlandırılmış partial HNSW index'leri graph'ı küçük ve recall'ı yüksek tutar; pgvector ayrıca seçici filtreler için exact fallback'li iterative index scan'leri belgeler. Değişen bir belgeyi yeniden embed'lemek ve eski vektörleri silmek de içerik güncellemesiyle aynı transaction'da yapılabilir — tek veritabanında kolay, iki veritabanında dağıtık bir tutarlılık problemi.

Özel motorun hâlâ kazandığı yerler

Yazı üç vakayı kabul ediyor: object-storage tiering'in fiilen iş modeli olduğu Notion ölçeğindeki multi-tenant iş yükleri; HNSW graph'ının verinin kendisinden daha fazla RAM talep ettiği 100 milyonluk vektör eşiğini aşan çok büyük tek index'ler; ve belge başına düzinelerce vektör saklayan ColBERT gibi late-interaction, multi-vector retrieval — tam da turbopuffer v3'ün çözmek için var olduğu amplification problemi ve satır tabanlı Postgres depolaması için de kötü bir uyum. Yazarın kapanış gözlemi, bunların ölçek problemleri olduğu ve lansmandan önce bunları tartışan ekiplerin yanlış şeyi tartıştığı yönünde.

Neden önemli

Bu döngünün en başarılı vector-search şirketi, vektörlere özel muamele etmenin diğer her şeyi kötüleştirdiği sonucuna vardı. Bu, embedding'ler ortaya çıkar çıkmaz özel bir vector veritabanı ekleme refleksini zayıflatıyor ve pazarın yüksek ucunun gerçekte ne sattığını yeniden çerçeveliyor: milyarlarca vektörde depolama ekonomisi ve tiering, index'in kendisi değil. Çoğu ekip için pratik çıkarım Postgres'te başlamak, gerçekten çalıştırdığınız sorgu şekillerine göre tasarlamak ve herhangi bir göçü benchmark yazılarının değil, ölçülmüş ölçeklerin dayatması.