Kebanyakan tim yang butuh pencarian sekaligus analitik menjalankan minimal dua database. Elasticsearch atau OpenSearch menangani full-text search, ClickHouse atau warehouse menangani query analitik, dan Postgres menyimpan data transaksional. SereneDB adalah proyek open source yang mencoba meruntuhkan tumpukan itu menjadi satu engine: database yang kompatibel dengan Postgres, dengan pencarian dan analitik yang dibangun ke dalam engine query yang sama, di atas data yang sama.
Poin Penting
>
SereneDB menyatukan pencarian ala Elasticsearch dan analitik ala ClickHouse dalam satu database yang kompatibel dengan Postgres, menurut README-nya.
Ia berbicara protokol wire PostgreSQL (v3.0) di port 7890, jadi kebanyakan klien, driver, dan tool BI Postgres terhubung tanpa perubahan kode.
Pencarian adalah bagian kelas satu dari SQL: operator
@@melakukan full-text matching dengan ranking BM25, dan vector search berjalan dalam statement yang sama terhadap index yang sama.Versi production-ready pertamanya, Krummelanke, dirilis pada 22 September 2026 di bawah Apache 2.0, tetapi baru sebagai single node. Clustering multi-node penuh masih ada di roadmap.
Saat artikel ini ditulis, ia punya 955 bintang dan 76 fork di GitHub. Angka SearchBench yang dipublikasikannya adalah benchmark vendor dengan metodologi terbuka, bukan verifikasi independen.
Kamu bisa mencobanya dengan satu perintah Docker, tanpa kredensial secara default.
Tonton signal repo 30 detiknya
Sebenarnya SereneDB Itu Apa
SereneDB, oleh serenedb, menggambarkan dirinya sebagai "The First Real-Time Search Analytics Database". Dalam bahasa sederhana, ia adalah satu engine yang menjalankan full-text search, vector search, dan analitik SQL di atas tabel yang sama, dengan satu inverted index per tabel, yang di-query dengan SQL biasa. Tidak ada klaster pencarian terpisah yang harus dijaga sinkron dengan penyimpanan analitik, karena hanya ada satu penyimpanan.
Proyek ini masih muda tetapi sudah melewati tonggak production pertamanya. Ia dibuat pada 31 Agustus 2025, dan versi production-ready pertamanya, Krummelanke, rilis pada 22 September 2026, seperti dilaporkan StartupRise. Perusahaan di baliknya adalah startup Berlin yang didirikan pada 2025, dengan tim 8 orang dan pendanaan pre-seed $2,1 juta pada Desember 2025 yang dipimpin Entourage dan High-Tech Gründerfonds, menurut Tech Funding News. Versi single-node yang lengkap dinyatakan akan tetap Apache 2.0 selamanya, yang penting kalau kamu mengevaluasinya sebagai infrastruktur open source, bukan sebagai tier gratis dari produk komersial.
Kenapa Pencarian dan Analitik Biasanya Butuh Dua Database
Pencarian dan analitik menarik engine penyimpanan ke arah yang berlawanan. Pencarian butuh inverted index, ranking relevansi, dan pengambilan cepat atas sedikit dokumen yang cocok. Analitik butuh pemindaian kolom, agregasi, dan pemrosesan cepat atas jutaan baris. Database tradisional hanya bagus di salah satunya, jadi tim membagi pekerjaan: Postgres untuk transaksi, Elasticsearch untuk pencarian, ClickHouse untuk analitik, plus pipeline untuk memindahkan data di antara ketiganya.
Pembagian itu punya biaya nyata. Setiap pipeline adalah tempat di mana data bisa basi, rusak, atau tidak sinkron, dan setiap sistem tambahan adalah satu hal lagi yang harus dioperasikan, dimonitor, dan dibayar. Taruhan SereneDB adalah satu engine bisa mengerjakan kedua tugas itu dengan cukup baik sehingga pembagian tersebut tidak lagi sepadan untuk analitik log, observability, dan workload AI, yang memang workload di mana query pencarian dan analitik menghantam data yang sama.
Cara Kerjanya
Kompatibilitas Postgres SereneDB ada di level wire-protocol. Ia mengimplementasikan PostgreSQL wire protocol v3.0 di port 7890, jadi psql dan kebanyakan driver Postgres terhubung langsung. Koneksi dasarnya terlihat seperti ini:
psql -h localhost -p 7890 -U postgres
Tidak ada kredensial yang dibutuhkan secara default, yang praktis untuk uji coba lokal dan wajib diubah sebelum deployment sungguhan.
Pencarian hidup di dalam SQL, bukan di balik API terpisah. Operator @@ melakukan full-text matching dengan ranking BM25, ts_phrase menangani query frasa, dan vector search memakai index ivf dengan operator jarak <=>, jadi lexical recall dan semantic ranking bisa berjalan dalam satu statement terhadap satu index. Fungsi ai_embed menghasilkan embedding dari SQL, jadi workload AI bisa melakukan embedding, penyimpanan, dan retrieval tanpa meninggalkan database.
Ia juga mengusung cerita zero-ETL. SereneDB membaca Parquet, CSV, dan JSON secara langsung, dan bisa meng-index data di tempat (in place) di S3 atau HDFS, termasuk tabel Parquet dan Iceberg. Tabel Postgres atau ClickHouse jarak jauh bisa di-query lewat foreign server CREATE SERVER. Baris baru menjadi searchable pada refresh index berikutnya, setiap detik secara default, menurut situs resminya. Klaim kesegaran itu yang membuatnya masuk akal untuk kasus log dan observability, di mana data kemarin saja tidak cukup.
Aspek | SereneDB | Elasticsearch | ClickHouse | Postgres |
|---|---|---|---|---|
Full-text search | Bawaan, kelas satu | Kekuatan utama | Lemah, bukan tugasnya | Dasar, lewat ekstensi |
Analitik SQL | Bawaan | Terbatas, lewat plugin SQL | Kekuatan utama | Kekuatan utama |
Protokol wire Postgres | Ya, v3.0 di port 7890 | Tidak | Tidak | Native |
Vector search | Bawaan, index yang sama | Lewat plugin dan dense vector | Lewat fungsi jarak | Lewat pgvector |
Production single-node | Ya, sejak Krummelanke | Ya | Ya | Ya |
Clustering terdistribusi | Di roadmap, federasi untuk saat ini | Matang | Matang | Lewat ekstensi |
Angka SearchBench, Dengan Catatan
SereneDB mempublikasikan benchmark-nya sendiri, SearchBench: 92 query pencarian dan analitik di atas log OpenTelemetry pada 100 juta, 1 miliar, dan 10 miliar baris, dengan batas 60 detik per query, satu node per engine, dan cache hasil dimatikan. Metodologi dan adapter-nya dipublikasikan, yang lebih baik daripada klaim marketing kosong, tetapi angka di bawah ini tetap hasil vendor sendiri, bukan pengujian independen.
Pada 1 miliar log, tulisan SearchBench resmi melaporkan median latensi hot 32,5 ms untuk SereneDB, dengan 92 dari 92 query selesai dan 112,1 GiB di disk, berbanding 98,4 ms untuk Elasticsearch 9.5 (88 dari 92 selesai, 153,2 GiB), 195,2 ms untuk OpenSearch 3.8, dan 543,5 ms untuk CrateDB 6.4. Mesin ujinya adalah satu instance GCP n2-standard-32 dengan 32 vCPU dan RAM 128 GB. Beranda-nya merangkum run yang sama sebagai geomean 1,11x untuk SereneDB, berbanding 3,45x untuk Elasticsearch, 14,21x untuk ClickHouse, dan 50,69x untuk Postgres, plus waktu load 5 menit 10 detik berbanding 3 jam 19 menit untuk Elasticsearch.
Klaim headline di README bahwa ia 10 kali lebih cepat daripada ClickHouse pada 10 miliar log OpenTelemetry masuk kategori yang sama: klaim perusahaan, yang diulang oleh liputan pers, bukan pengukuran yang terverifikasi secara independen. Satu detail yang menggembirakan dari Tech Funding News adalah tim ClickHouse sendiri mengajukan perubahan benchmark yang kemudian dimasukkan SereneDB ke dalam pengujian ulang, yang merupakan validasi luar terdekat yang ditemukan sejauh ini. Perlakukan benchmark itu sebagai alasan untuk mencobanya pada workload-mu sendiri, bukan sebagai bukti.
Kematangan dan Batasan
Krummelanke sudah production-ready untuk deployment single-node, tetapi scale-out saat ini bekerja lewat federasi, dan clustering multi-node penuh ada di roadmap publik untuk tahun depan, dengan edisi enterprise yang mencakup clustering, high availability, dan keamanan yang diperkirakan hadir pada Q4, menurut StartupRise dan Blocks and Files. Itulah kerangka evaluasi yang jujur: kalau workload-mu muat di satu node besar, SereneDB adalah kandidat nyata hari ini. Kalau kamu butuh klaster terdistribusi dengan failover, ia belum sampai di sana, dan fitur enterprise di sekitar itu bukan open source.
Batasan lain yang layak dicatat: proyek ini baru berumur sekitar satu tahun, dengan 836 commit dan 39 rilis, jadi rekam jejak stabilitas jangka panjangnya masih pendek. Dan meskipun protokol wire Postgres mencakup kebanyakan klien, kompatibilitas wire tidak sama dengan kompatibilitas Postgres penuh, jadi fitur dan ekstensi khusus Postgres harus diuji, bukan diasumsikan.
Cara Mencobanya
Dokumen quick start menawarkan satu binary, skrip installer, atau Docker:
docker run -d --name serenedb -p 7890:7890 -e SERENEDB_HOST_AUTH_METHOD=trust serenedb/serenedb
Dari sana, psql terhubung di port 7890, dan kamu bisa memuat file Parquet atau mengarahkannya ke bucket S3 lalu mulai menjalankan query pencarian @@ dan SQL analitik terhadap tabel yang sama. Uji coba satu perintah itu adalah cara tercepat untuk menilai apakah cerita benchmark-nya bertahan pada datamu sendiri.
Pertanyaan yang Sering Ditanyakan
Apakah SereneDB adalah fork dari Postgres?
Bukan. Ia adalah engine terpisah yang mengimplementasikan PostgreSQL wire protocol v3.0, jadi klien Postgres terhubung dengannya, tetapi ia bukan Postgres itu sendiri, dan core pencariannya dibangun di atas library information retrieval IResearch.
Apakah ia menggantikan Elasticsearch, ClickHouse, dan Postgres sekaligus?
Hanya untuk workload di mana pencarian dan analitik menghantam data yang sama, seperti log dan observability. Ia tidak bertujuan menggantikan Postgres sebagai sistem transaksional, dan cerita clustering-nya belum cukup matang untuk menggantikan deployment Elasticsearch atau ClickHouse terdistribusi.
Apakah semuanya open source?
Versi single-node yang lengkap adalah Apache 2.0, dan perusahaan menyatakan akan tetap seperti itu. Fitur clustering, high availability, dan keamanan direncanakan untuk edisi enterprise.
Seberapa segar data yang baru ditulis?
Baris baru menjadi searchable pada refresh index berikutnya, setiap detik secara default, menurut situs resminya. Itu membuatnya cocok untuk pencarian log yang nyaris real-time, bukan untuk pembacaan transaksional sub-detik.
SereneDB adalah proyek muda dengan klaim berani: bahwa pencarian dan analitik seharusnya ada dalam satu engine, dan engine itu bisa berbicara Postgres. Angka benchmark-nya menjanjikan tetapi dipublikasikan sendiri, dan roadmap clustering-nya belum selesai, jadi langkah yang tepat adalah uji coba pada log-mu sendiri, bukan migrasi atas dasar keyakinan. Kalau uji coba itu bertahan, satu database yang mengerjakan dua tugas adalah tumpukan yang sungguh lebih sederhana.