Bagian tersulit dalam membangun fitur AI sering kali bukan modelnya. Bagian tersulit adalah menemukan catatan yang tepat. Catatan itu harus ditemukan dengan cepat. Tempatnya adalah basis data yang sudah berjalan. Pinecone pg_pinecone adalah ekstensi sumber terbuka untuk Postgres. Ekstensi ini membawa pencarian vektor Pinecone ke dalam Postgres. Ekstensi ini bekerja pada kolom pgvector yang sudah Anda simpan. Ekstensi ini mempertahankan tabel dan SQL Anda. Pada mesin bawaannya, data Anda tidak pernah meninggalkan Postgres (pinecone-io/pg_pinecone, GitHub, diakses 27 Oktober 2026). Pinecone mengumumkan pg_pinecone pada 27 Oktober 2026. Rilisnya memakai Lisensi Apache 2.0. Gagasannya sederhana. Pencarian yang dulu membutuhkan sistem kedua kini berjalan di tempat data sudah berada.
Poin Penting
pg_pinecone adalah ekstensi sumber terbuka untuk Postgres. Pinecone merilisnya pada 27 Oktober 2026. Lisensinya adalah Lisensi Apache 2.0. Ekstensi ini menambahkan pencarian vektor ke kolom pgvector yang sudah Anda miliki.
Setiap tabel memakai satu dari tiga mesin. Mesin itu adalah mesin asli, mesin pgvector, atau mesin jarak jauh. Pergantian mesin memakai satu panggilan pinecone.set_engine(). Kueri Anda tidak berubah.
Mesin asli bawaan menyimpan kode RaBitQ yang ringkas. Kode itu disimpan di dalam gugus, bukan di dalam graf. Indeksnya tetap kecil. Penyaring diterapkan selama pencarian, bukan sesudahnya.
Dalam tolok ukur Pinecone sendiri, datanya 1 juta vektor berdimensi 768. Indeks mesin asli berukuran 136 MB. HNSW pada halfvec berukuran 2,0 GB. HNSW pada vektor berukuran penuh berukuran 4,1 GB.
Mesin asli tidak membutuhkan akun Pinecone. Mesin ini tidak membutuhkan kunci API. Mesin ini tidak membutuhkan panggilan jaringan. Fitur opsional Pinecone membutuhkan kunci API. Fitur itu adalah mesin jarak jauh, embed(), pencarian BM25, dan rerank().
Untuk memahami mengapa hal ini penting, mulailah dari susunan yang biasa dipakai. Asisten dukungan perlu menemukan catatan dengan cepat. Mesin rekomendasi produk juga demikian. Agen yang mengingat pekerjaan sebelumnya juga demikian. Bagi banyak tim, catatan itu tersimpan di Postgres. Memindahkannya ke basis data vektor terpisah berarti menjalankan sistem kedua. Artinya, salinan data harus dijaga tetap selaras. Artinya, ada satu lagi titik kegagalan. pg_pinecone menghilangkan salinan itu untuk kasus yang umum. Tabel tetap di Postgres. Postgres tetap menjadi sistem pencatat utama. Pencarian berjalan di basis data yang sama.
Apa Itu pg_pinecone?
pg_pinecone adalah ekstensi Postgres untuk pencarian. Pencarian itu ditujukan pada data yang sudah Anda simpan. Rumusan itu singkat dan akurat. Rumusan itu layak diuraikan kata demi kata. Ekstensi ini bukan basis data terpisah. Anda memasangnya ke Postgres. Anda mengaktifkannya dengan CREATE EXTENSION pg_pinecone. Ekstensi ini untuk pencarian. Khususnya, ekstensi ini untuk pencarian vektor. Sebagai pilihan, ekstensi ini untuk pencarian kata kunci. Ekstensi ini bekerja pada data yang sudah Anda simpan. Ekstensi ini mengindeks kolom vektor pgvector yang sudah ada. Ekstensi ini tidak meminta Anda memindahkan data ke penyimpanan baru.
Pencarian vektor adalah pencarian berdasarkan makna. Pencarian ini bukan berdasarkan kata yang persis sama. Sebuah teks diubah menjadi embedding. Embedding adalah daftar panjang angka. Daftar itu menangkap makna teks tersebut. Basis data lalu mencari embedding tersimpan yang paling dekat. Kedekatan itu diukur terhadap embedding kueri. pgvector adalah ekstensi Postgres yang sudah mapan. Ekstensi ini menambahkan tipe kolom vektor ke Postgres. Ekstensi ini menambahkan operator jarak ke Postgres. pg_pinecone dibangun di atas tipe kolom itu. Aplikasi yang sudah mengirim SQL tertentu dapat terus mengirim SQL yang sama. SQL itu, for example, adalah ORDER BY embedding <=> $1 LIMIT 10.
Repositori proyek ini dibuka di GitHub pada 26 Oktober 2026. Pembukaan itu terjadi sehari sebelum pengumuman. Pada saat artikel ini ditulis, repositori itu mencatat 44 commit. Repositori itu mencatat 23 star. Repositori itu mencatat 2 rilis. Lisensinya adalah Lisensi Apache 2.0 (pinecone-io/pg_pinecone, GitHub, diakses 27 Oktober 2026). Pinecone menyebutnya rilis pertama proyek ini. Pinecone menyatakan memelihara pg_pinecone. Pinecone menyatakan meninjau setiap pull request. Itu rumusan yang jujur. Ini perangkat lunak hari pertama. Perusahaan di baliknya memiliki bisnis basis data vektor terkelola yang besar. Ini bukan proyek komunitas matang. Proyek ini belum memiliki riwayat produksi bertahun-tahun.
Aspek | pg_pinecone |
|---|---|
Dirilis | 27 Oktober 2026 |
Lisensi | Lisensi Apache 2.0 |
Dibangun oleh | Pinecone |
Bekerja dengan | Postgres 17 atau 18, pgvector, akses superuser |
Mesin bawaan | mesin asli, di dalam Postgres, tanpa akun atau panggilan jaringan |
Tambahan opsional | mesin jarak jauh, embed(), pencarian BM25, rerank(), semua membutuhkan kunci API |
Status | Rilis pertama |
Tiga Mesin di Balik Satu Indeks
Keputusan desain yang membuat pg_pinecone menarik bukanlah satu algoritme pencarian. Keputusan itu adalah menempatkan tiga mesin di balik satu indeks. Satu tabel dapat berpindah di antara ketiganya. Setiap tabel memakai satu mesin pada satu waktu. Perpindahan memakai satu panggilan ke pinecone.set_engine(). Kueri Anda tidak berubah. Setiap perpindahan dapat dibatalkan. Hal itu sesuai dokumentasi proyek (pinecone-io/pg_pinecone, GitHub, diakses 27 Oktober 2026).
Mesin | Tempat pencarian berjalan | Dipakai untuk |
|---|---|---|
asli (bawaan) | Di dalam basis data Postgres Anda | Pencarian tersaring dan tidak tersaring, dengan indeks kecil dan tanpa panggilan jaringan |
pgvector | Indeks HNSW atau IVFFlat milik pgvector, di Postgres | Tabel yang sudah memiliki indeks pgvector dan tidak menyaring |
jarak jauh | Indeks tanpa server Pinecone | Tabel yang sudah melampaui satu server Postgres |
Mesin asli adalah mesin bawaan. Mesin asli adalah kisah utama rilis ini. Mesin ini membangun indeksnya sepenuhnya di dalam Postgres. Mesin ini mencari indeksnya sepenuhnya di dalam Postgres. Mesin ini tidak membutuhkan akun Pinecone. Mesin ini tidak membutuhkan kunci API. Mesin ini tidak membutuhkan panggilan jaringan. Mesin pgvector mencari indeks pgvector yang sudah ada. Mesin itu berguna bila Anda sudah menjalankannya. Mesin itu berguna bila Anda tidak membutuhkan penyaringan mesin asli. Mesin jarak jauh mengirim pencarian ke layanan terkelola Pinecone. Mesin itu untuk tabel yang sudah melampaui satu server Postgres. Dengan mesin jarak jauh, embedding Anda diselaraskan ke Pinecone di latar belakang. Pencarian tetap berjalan di Postgres sampai salinannya selesai. Postgres tetap menjadi sumber kebenaran.
Tangga itu penting. Tangga itu mengubah biaya dari pilihan yang keliru. Sebuah tim dapat memulai pada mesin asli. Mesin asli berjalan di dalam Postgres. Tim itu dapat memindahkan satu tabel ke layanan terkelola belakangan. Pemindahan itu tidak membutuhkan penulisan ulang kueri. Tim itu juga dapat kembali. Ekstensi ini karena itu bukan sekadar taruhan pada satu bentuk penerapan. Ekstensi ini adalah cara menunda keputusan itu. Keputusan itu ditunda sampai data memaksanya.
Cara Mesin Asli Mencari
Seperti HNSW milik pgvector, mesin asli memakai algoritme tetangga terdekat aproksimatif. Tetangga terdekat aproksimatif adalah metode pencarian yang menemukan kecocokan yang sangat dekat dengan cepat. Metode ini tidak menjamin kecocokan terdekat secara matematis setiap waktu. Perbedaannya terletak pada apa yang disimpan indeks. Perbedaannya terletak pada cara indeks itu ditelusuri. HNSW menyimpan graf. Graf itu berisi salinan penuh setiap vektor. Graf itu berisi tautan ke tetangga terdekatnya. Pencarian menelusuri graf itu. Pencarian membandingkan vektor penuh pada setiap lompatan. Seluruh graf harus tetap berada di memori agar cepat.
Mesin asli mengganti graf dengan indeks berkas terbalik. Indeks itu biasa disebut IVF. Indeks itu mengelompokkan vektor serupa ke dalam gugus. Indeksnya menyimpan ringkasan ringkas setiap vektor. Ringkasan itu adalah kode RaBitQ. Kode itu sekitar satu bit per dimensi. Kode itu ditambah beberapa nilai koreksi. Metode itu dikreditkan kepada Gao dan Long. Makalahnya terbit di SIGMOD 2024. Kode untuk setiap gugus dikemas bersama. Pencarian membaca beberapa halaman yang berurutan. Pencarian tidak melompat melintasi graf. Pencarian lalu berjalan dalam tiga langkah. Langkah pertama menyelidiki gugus terdekat. Penyelidikan itu membandingkan vektor kueri dengan pusat setiap gugus. Langkah kedua menghitung jarak perkiraan untuk setiap baris. Jarak itu dihitung dari kode RaBitQ-nya. Langkah kedua menyimpan kandidat terbaik. Langkah ketiga menyusun ulang kandidat itu. Penyusunan ulang memakai vektor penuh dari tabel Anda.
Itulah sebabnya indeksnya jauh lebih kecil. Ringkasan lebih murah disimpan daripada vektor penuh. Ringkasan lebih murah disimpan daripada tautan graf. Tata letak bergugus lebih murah dibaca daripada penelusuran graf. Pertukarannya adalah langkah perkiraan harus cukup baik. Kecocokan terbaik yang sesungguhnya harus bertahan ke daftar pendek. Daftar pendek itu dipakai untuk penyusunan ulang. Angka tolok ukur Pinecone, yang dibahas di bawah, adalah bukti Pinecone. Bukti itu menunjukkan hal itu terjadi. Bukti itu berlaku setidaknya pada data uji yang dipilihnya.
Masalah Penyaring, dan Mengapa Ia Lebih Penting daripada Kecepatan
Sebagian besar pencarian nyata disaring. Asisten dukungan mencari tiket satu pelanggan. Toko mencari produk satu penyewa. Agen mencari catatan satu pengguna. Penyaring itu biasanya klausa WHERE. Klausa itu berada pada kolom seperti tenant_id. Pertanyaannya adalah kapan klausa itu diterapkan. Jawabannya menentukan apakah hasilnya lengkap.
HNSW milik pgvector menyaring sesudah pencarian. HNSW menemukan tetangga terdekat dulu. HNSW lalu menerapkan klausa WHERE. Dengan penyaring sempit, sebagian besar kandidat dibuang. Penyaring sempit, for example, adalah satu penyewa dari seratus penyewa. Kueri dapat mengembalikan baris lebih sedikit daripada LIMIT-nya. Pemindaian berulang milik pgvector mengisi daftar itu. Pemindaian itu mencari lebih jauh. Pemindaian itu membutuhkan biaya waktu. Pemindaian itu membutuhkan biaya akurasi bila relaxed_order dipakai. Hal itu sesuai pengumuman Pinecone (pengumuman Pinecone, diakses 27 Oktober 2026).
Mesin asli menyaring selama pencarian. Mesin ini memilih strateginya berdasarkan selektivitas. Mesin ini menyimpan nilai satu kolom penyaring di samping kode RaBitQ setiap baris. Pada saat pembangunan, mesin ini menghitung berapa baris yang membawa setiap nilai. Untuk penyaring sempit, mesin ini menyaring lebih dulu. Penyaring sempit adalah 3 persen baris atau kurang secara bawaan. Mesin ini memindai setiap baris yang cocok di semua gugus. Mesin ini menilai masing-masing dengan vektor penuhnya. Hasilnya eksak. Untuk penyaring yang lebih lebar, mesin ini memakai penyaringan satu tahap. Penyaring yang lebih lebar adalah lebih dari 3 persen baris. Mesin ini mencari lebih banyak gugus terdekat daripada pencarian tanpa penyaring. Jumlahnya sampai setengahnya. Mesin ini memeriksa penyaring di dalam setiap gugus sebelum menilai.
Perbedaan itu adalah argumen terkuat untuk mesin asli. Argumen itu lebih kuat daripada kecepatan mentah. Kecepatan mudah dibeli dengan memori yang lebih besar. Kelengkapan pada penyaring sempit adalah sifat kebenaran. Pencarian yang diam-diam mengembalikan baris lebih sedikit daripada yang diminta adalah galat. Galat itu tampak seperti fitur yang hilang bagi pengguna. Bila beban kerja Anda sebagian besar tidak tersaring, keunggulan ini kurang penting. Mesin pgvector mungkin sudah cukup. Bila beban kerja Anda per penyewa atau per pengguna, keunggulan ini sangat penting.
Menjaga indeks tetap mutakhir lebih sederhana daripada pencarian itu sendiri. Saat Anda menyisipkan baris baru, setiap vektor bergabung dengan gugus terdekat. Vektor itu langsung dapat dicari. Pusat gugus tetap di tempat pembangunan menaruhnya. Setelah perubahan besar, Pinecone menyarankan menjalankan REINDEX. Perubahan besar, for example, adalah pemuatan massal yang menggandakan tabel. Perubahan besar lainnya adalah data baru yang tidak menyerupai data saat indeks dibangun. Pinecone juga menyarankan mengaktifkan pemeliharaan otomatis. Pemeliharaan itu menyeimbangkan kembali gugus. Itu biaya operasional yang wajar untuk indeks bergugus. Biaya itu harus direncanakan dalam setiap pemuatan massal. Biaya itu tidak boleh ditemukan sesudahnya.
Tolok Ukur: Apa yang Dilaporkan Pinecone, dan Apa yang Perlu Diwaspadai
Semua angka tolok ukur pada bagian ini adalah angka Pinecone sendiri. Angka itu dilaporkan dalam pengumumannya. Angka itu dilaporkan dalam perangkat tolok ukurnya. Angka itu belum direproduksi secara independen dalam liputan yang terbit. Peringatan itu perlu diletakkan di depan. Angkanya mencolok. Perusahaan yang menjual layanan terkelola itu juga menulis pengujiannya. Susunannya, seperti yang dideskripsikan Pinecone, adalah 1 juta vektor wiki_dpr berdimensi 768. Instansnya adalah AWS r6id.4xlarge. Instans itu memiliki 16 vCPU dan RAM 128 GB. Latensi tanpa penyaring diukur dalam satu sesi pada PostgreSQL 17. Waktu pembangunan dan ukuran indeks diukur dalam sesi yang sama. Pencarian tersaring diukur pada sesi lain pada PostgreSQL 18. Konfigurasi dengan memori dibatasi diukur pada sesi ketiga. Latensi adalah median p50 pada k sama dengan 10 dengan satu klien. Hal itu berlaku kecuali dinyatakan lain. Metode pengujian ini penting. Metode ini menentukan seberapa jauh angka itu dapat dipercaya.
Ukuran (1 juta vektor, 768 dimensi) | pg_pinecone asli | HNSW pada halfvec | HNSW pada vektor berukuran penuh |
|---|---|---|---|
Ukuran indeks | 136 MB | 2,0 GB | 4,1 GB |
Waktu pembangunan indeks | 45 detik | 62 detik | 79 detik |
Latensi pada recall 0,95 | 1,3 md | 1,7 md | 2,7 md |
Latensi pada recall 0,99 | 2,3 md | 4,7 md | 6,7 md |
Tersaring, 10 persen cocok | recall 1,000 dalam 12,3 md | recall 0,920 terbaik dalam 5,9 md (pemindaian berulang) | Tidak dilaporkan terpisah |
Tersaring, 1 persen cocok | recall 0,981 dalam 8,3 md | recall 0,924 dalam 56 md | Tidak dilaporkan terpisah |
Bacalah tabel itu dalam dua bagian. Kesenjangan ukuran indeks dan waktu pembangunan besar. Kesenjangan itu struktural. Indeks ringkasan bergugus seharusnya lebih kecil. Indeks itu seharusnya lebih cepat dibangun daripada graf vektor penuh. Angka 136 MB berbanding 2,0 GB dan 4,1 GB adalah kesenjangan yang besar. Kesenjangan itu mengubah apakah indeks muat di memori atau tidak (pengumuman Pinecone, diakses 27 Oktober 2026). Kesenjangan latensi lebih kecil. Kesenjangan itu datang dengan pertukaran. Pada penyaring 10 persen, mesin asli mencapai recall 1,000 dalam 12,3 md. HNSW dengan pemindaian berulang mencapai recall 0,920 terbaik dalam 5,9 md. Mesin asli lebih akurat di sana. Mesin asli lebih lambat dalam waktu absolut. Mesin asli mencari lebih banyak gugus agar penyaringnya tepat. Itu pertukaran yang masuk akal untuk beban kerja tersaring. Itu pertukaran yang buruk bila Anda hanya peduli kecepatan mentah pada kueri tanpa penyaring.
Liputan independen sejauh ini menyatakan ulang angka Pinecone. Liputan itu tidak menjalankannya kembali. Liputan peluncuran Unite.AI melaporkan ukuran indeks yang sama. Liputan itu melaporkan latensi yang sama. Liputan itu melaporkan perilaku penyaring yang sama. Liputan itu mencatat tiga mesin yang sama. Liputan itu mencatat bawaan yang sama. Bawaan itu adalah tanpa akun atau panggilan jaringan pada mesin asli. Perlakukan tabel tolok ukur di atas sebagai klaim. Klaim itu perlu diverifikasi pada data Anda sendiri. Klaim itu bukan hasil yang sudah pasti. Perangkat tolok ukur itu ada di repositori. Sebuah tim dapat menjalankan ulang pengujian itu sebelum berkomitmen pada ekstensi ini. Itu langkah berikutnya yang tepat untuk setiap keputusan produksi.
Cara Mencoba pg_pinecone
Syaratnya sempit. Periksalah dulu. pg_pinecone membutuhkan PostgreSQL 17 atau 18. pg_pinecone membutuhkan akses superuser. pg_pinecone membutuhkan pgvector yang terpasang di server (pinecone-io/pg_pinecone, GitHub, diakses 27 Oktober 2026). Ekstensi ini dipasang dari rilis prabangun di GitHub. Ekstensi ini dipasang sebagai citra pineconeteam/pg_pinecone di Docker Hub. Menurut README, citra itu adalah citra pgvector dengan pg_pinecone ditambahkan. Citra itu memiliki satu tag per versi utama Postgres. Ekstensi ini juga dapat dibangun dari sumber. Pembangunan itu memakai perkakas Rust dan cargo-pgrx 0.19.2. Bila Docker masih baru bagi Anda, penjelasan Docker kami membahas apa itu container dan mengapa pengembang menyukainya.
Langkah cepatnya, dari pengumuman, singkat. Buat tabel dengan kolom vektor. Aktifkan ekstensi. Bangun indeks. Kueri seperti biasa. Perintahnya adalah CREATE EXTENSION pg_pinecone. Perintah berikutnya adalah SELECT pinecone.create_index('docs', 'embedding', filter_column => 'tenant_id'). Perintah kuerinya adalah SELECT id, body FROM docs WHERE tenant_id = $1 ORDER BY embedding <=> $2 LIMIT 10. Argumen filter_column layak ditetapkan sejak awal. Hal itu berlaku bila beban kerja Anda menyaring menurut penyewa atau pengguna. Argumen itulah yang membuat penyaringan selama pencarian pada mesin asli bekerja.
Dua catatan operasional layak ditekankan. Pertama, menjalankan mesin jarak jauh juga membutuhkan pemuatan ekstensi lewat shared_preload_libraries. Itu merupakan perubahan konfigurasi server. Itu bukan sekadar pernyataan SQL. Rencanakan jendela mulai ulang. Kedua, dokumentasi ekstensi di docs.pinecone.io membahas pemasangan. Dokumentasi itu membahas mesin penyimpanan. Dokumentasi itu membahas perpindahan mesin. Dokumentasi itu membahas pencarian teks penuh. Repositori menambahkan referensi SQL. Repositori menambahkan buku panduan operator. Repositori menambahkan panduan pemulihan bencana. Bacalah buku panduan operator sebelum pemasangan produksi. Jangan membacanya sesudah insiden pertama.
Fitur Opsional Pinecone, dan Biayanya
Mesin asli gratis dalam arti yang paling penting. Mesin ini tanpa akun. Mesin ini tanpa kunci. Mesin ini tanpa jaringan. Mesin ini tanpa tagihan dari Pinecone. Semua hal lain dalam pengumuman bersifat opsional. Semua hal lain terikat pada kunci API Pinecone. Pemisahan itu rapi. Pemisahan itu juga sebuah corong. Pemisahan itu harus disebut demikian.
Dengan kunci API, ekstensi yang sama memberi Anda empat alat lagi. Setiap alat bersifat opsional. Setiap alat ditambahkan satu per satu. Mesin jarak jauh memindahkan pencarian ke layanan terkelola Pinecone. Pemindahan itu memakai satu perintah SQL. Perintah itu adalah SELECT pinecone.set_engine('docs', 'remote'). Fungsi embed() memanggil layanan inferensi Pinecone. Panggilan itu mengubah teks menjadi embedding dari SQL. Tabel yang berisi teks tetapi belum memiliki embedding dapat diisi dengan cara itu. Cara itu tidak membutuhkan penghostingan model. Cara itu tidak membutuhkan pengelolaan kunci penyedia lain. Pinecone menyatakan tingkat gratisnya menanggung pembangunan pertama. Pencarian teks penuh BM25 berjalan berdampingan dengan pencarian vektor pada tabel yang sama. Pencarian itu untuk istilah persis, such as nama produk atau kode galat. Pencarian itu juga untuk pencarian berdasarkan makna. Dan rerank() menyusun ulang hasil teratas dengan model penyusunan ulang Pinecone. Hal itu membantu bila hanya beberapa hasil teratas yang penting. Hal itu berlaku, for example, dalam retrieval augmented generation. Hal itu berlaku bila hasil kata kunci dan hasil vektor digabung menjadi satu daftar.
Tidak satu pun dari fitur itu mengubah tempat pencarian berjalan. Pengecualiannya adalah mesin jarak jauh itu sendiri. Hanya panggilan embed yang membutuhkan Pinecone, dalam kasus embed. Hanya panggilan rerank yang membutuhkan Pinecone, dalam kasus rerank. Pemisahan itu adalah desain yang baik. Sebuah tim dapat memakai embed() untuk memulai tabel. Tim itu lalu menjalankan semua pencarian secara lokal pada mesin asli. Tim itu tidak membayar apa pun di luar tingkat gratis untuk pembangunan pertama itu. Biaya yang perlu diwaspadai bukanlah ekstensi. Ekstensi itu adalah perangkat lunak Lisensi Apache 2.0. Biaya itu adalah panggilan terkelola. Panggilan itu dihargai menurut ketentuan layanan Pinecone. Biaya itu adalah pemindahan data. Pemindahan itu terjadi bila mesin jarak jauh menyelaraskan embedding ke luar Postgres.
Siapa yang Sebaiknya Memakai pg_pinecone, dan Siapa yang Sebaiknya Tidak
Kecocokan terbaik adalah tim yang sudah menjalankan Postgres 17 atau 18. Tim itu sudah menyimpan vektor di pgvector. Tim itu sebagian besar mencari di dalam satu penyewa. Tim itu sebagian besar mencari di dalam satu pengguna. Tim itu sebagian besar mencari di dalam satu kategori. Bagi tim itu, pg_pinecone menghilangkan sistem kedua. Bagi tim itu, pg_pinecone menjaga data di satu tempat. Bagi tim itu, pg_pinecone memperbaiki kasus penyaring sempit. Kasus itu ditangani buruk oleh penyaringan sesudah pencarian. Ekstensi ini juga cocok untuk tim yang ingin memulai dari yang kecil. Tim itu menjaga pilihan untuk pindah ke layanan terkelola belakangan. Perpindahan itu tidak membutuhkan penulisan ulang kueri.
Lewati dulu, bila Anda menjalankan versi Postgres yang lebih lama. Lewati dulu, bila Anda tidak dapat memperoleh akses superuser. Lewati dulu, bila beban kerja Anda tidak tersaring dan sudah cepat pada HNSW. Lewati mesin jarak jauh bila data Anda tidak boleh meninggalkan Postgres. Seluruh tujuan mesin itu adalah menyelaraskan embedding ke layanan Pinecone. Perlakukan label rilis pertama dengan serius. Pinecone menyatakan akan membangun peta jalan publik dari umpan balik. Umpan balik itu dibagikan lewat issue GitHub. Umpan balik itu dibagikan lewat komunitas Discord-nya. Umpan balik itu dibagikan lewat jam kantor bulanan. Rangkaian fitur masih ditemukan oleh pengguna awal. Kekasaran operasionalnya masih ditemukan oleh pengguna awal.
Pertanyaan terkait adalah bagaimana pg_pinecone berdampingan dengan kisah basis data lain di situs ini. Bila gagasan tentang basis data yang berubah bentuk menarik bagi Anda, artikel DuckDB 2.0 kami membahas basis data yang belajar menjadi server. Basis data itu tetap berada di dalam proses. pg_pinecone adalah jawaban berbeda untuk tekanan yang serupa. Pertahankan basis data yang Anda miliki. Bawalah beban kerja baru itu kepadanya. Jangan membawa data Anda ke basis data baru.
Pertanyaan yang Sering Diajukan
Apakah pg_pinecone gratis? Perangkat lunaknya gratis dan sumber terbuka dengan Lisensi Apache 2.0. Mesin asli tidak membutuhkan akun Pinecone. Mesin asli tidak membutuhkan kunci API. Mesin asli tidak membutuhkan panggilan jaringan. Menjalankannya hanya membebani infrastruktur Postgres Anda sendiri. Fitur opsional yang memanggil layanan Pinecone membutuhkan kunci API. Fitur itu adalah mesin jarak jauh, embed(), pencarian BM25 lewat Pinecone, dan rerank(). Fitur itu tunduk pada ketentuan layanan Pinecone.
Apakah pg_pinecone menggantikan pgvector? Tidak. pg_pinecone bekerja dengan kolom pgvector yang sudah Anda miliki. Salah satu dari tiga mesinnya adalah mesin pgvector itu sendiri. Mesin itu mencari indeks pgvector yang sudah ada. Ekstensi ini menambahkan mesin asli dan mesin jarak jauh. Mesin itu berada di balik kolom dan SQL yang sama. Ekstensi ini bukan mengganti tipe kolom. Ekstensi ini bukan mengganti kueri yang sudah Anda kirim.
Apakah data saya meninggalkan Postgres pada mesin bawaan? Tidak. Pada mesin asli bawaan, indeks dibangun sepenuhnya di dalam Postgres. Indeks dicari sepenuhnya di dalam Postgres. Mesin ini tanpa akun Pinecone. Mesin ini tanpa kunci API. Mesin ini tanpa panggilan jaringan. Data meninggalkan Postgres hanya bila Anda memilih mesin jarak jauh. Mesin itu menyelaraskan embedding ke indeks Pinecone. Data juga meninggalkan Postgres bila Anda memanggil layanan opsional Pinecone. Layanan itu, for example, adalah embed() atau rerank().
Versi Postgres apa yang didukung pg_pinecone? PostgreSQL 17 atau 18, dengan akses superuser dan pgvector yang terpasang di server, menurut README proyek. Ekstensi ini dipasang dari rilis prabangun di GitHub. Ekstensi ini dipasang sebagai citra Docker pineconeteam/pg_pinecone. Citra itu memiliki satu tag per versi utama Postgres. Ekstensi ini dapat dibangun dari sumber. Pembangunan itu memakai perkakas Rust dan cargo-pgrx 0.19.2.
Mengapa penyaringan selama pencarian penting? Karena penyaringan sesudah pencarian dapat mengembalikan baris lebih sedikit daripada yang diminta. Bila pencarian menemukan tetangga terdekat dulu, lalu menerapkan klausa WHERE untuk satu penyewa dari seratus penyewa, sebagian besar kandidat dibuang. Kueri dapat mengembalikan baris lebih sedikit daripada LIMIT-nya. Mesin asli menerapkan penyaring selama pencarian. Cakupan sempit tetap mengembalikan rangkaian hasil yang penuh. Untuk penyaring sempit sebesar 3 persen baris atau kurang, mesin ini menyaring lebih dulu. Hasilnya eksak.
Kesimpulan
pg_pinecone adalah ekstensi kecil dengan gagasan yang jelas. Basis data yang sudah Anda jalankan seharusnya dapat mencari data yang sudah Anda simpan. Pencarian itu tanpa sistem kedua. Pencarian itu tanpa diam-diam membuang hasil tersaring. Indeks bergugus dan terkompresi pada mesin asli sungguh lebih kecil daripada indeks graf. Penyaringan selama pencarian memperbaiki masalah kebenaran yang nyata untuk beban kerja multipenyewa. Tangga tiga mesin membiarkan tim memulai di dalam Postgres. Tim itu pindah keluar hanya bila data memaksanya. Tolok ukurnya adalah tolok ukur Pinecone sendiri. Tolok ukur itu harus dijalankan ulang pada data Anda sebelum komitmen produksi. Ini adalah rilis pertama. Kekasaran dapat diharapkan. Namun, bawaan yang dipilih adalah bawaan yang tepat. Bawaan itu tanpa akun. Bawaan itu tanpa kunci. Bawaan itu tanpa jaringan. Bawaan itu tanpa salinan data Anda. Mulailah dari repositori GitHub dan pengumuman resmi, atau bacalah versi bahasa Inggris artikel ini.