Most teams that need both search and analytics run at least two databases. Elasticsearch or OpenSearch handles full-text search, ClickHouse or a warehouse handles analytical queries, and Postgres holds the transactional data. SereneDB is an open source project that tries to collapse that stack into one engine: a Postgres-compatible database with search and analytics built into the same query engine, over the same data.
Key Takeaways
>
SereneDB unifies Elasticsearch-like search and ClickHouse-like analytics in a single, Postgres-compatible database, according to its README.
It speaks the PostgreSQL wire protocol (v3.0) on port 7890, so most Postgres clients, drivers, and BI tools connect without code changes.
Search is a first-class part of SQL: the
@@operator does full-text matching with BM25 ranking, and vector search runs in the same statement against the same index.Its first production-ready version, Krummelanke, was released on 22 September 2026 under Apache 2.0, but only as a single node. Full multi-node clustering is still on the roadmap.
At the time of writing it has 955 stars and 76 forks on GitHub. Its published SearchBench numbers are vendor benchmarks with open methodology, not independent verification.
You can try it with one Docker command, no credentials required by default.
Watch the 30-second repo signal
What SereneDB Actually Is
SereneDB, by serenedb, describes itself as "The First Real-Time Search Analytics Database". In plain terms, it is one engine that runs full-text search, vector search, and SQL analytics over the same tables, with one inverted index per table, queried with plain SQL. There is no separate search cluster to keep in sync with the analytical store, because there is only one store.
The project is young but already past its first production milestone. It was created on 31 August 2025, and its first production-ready version, Krummelanke, shipped on 22 September 2026, as reported by StartupRise. The company behind it is a Berlin startup founded in 2025, with an 8-person team and a $2.1M pre-seed round in December 2025 led by Entourage and High-Tech Gründerfonds, according to Tech Funding News. The complete single-node version is stated to stay Apache 2.0 forever, which matters if you are evaluating it as open source infrastructure rather than as a free tier of a commercial product.
Why Search and Analytics Usually Need Two Databases
Search and analytics pull a storage engine in opposite directions. Search needs inverted indexes, relevance ranking, and fast retrieval of a few matching documents. Analytics needs columnar scans, aggregations, and fast processing of millions of rows. Traditional databases do one of these well, so teams split the job: Postgres for transactions, Elasticsearch for search, ClickHouse for analytics, plus pipelines to move data between them.
That split has a real cost. Every pipeline is a place where data goes stale, breaks, or drifts out of sync, and every additional system is another thing to operate, monitor, and pay for. SereneDB's bet is that one engine can do both jobs well enough that the split is no longer worth it for log analytics, observability, and AI workloads, which are exactly the workloads where search and analytics queries hit the same data.
How It Works
SereneDB's Postgres compatibility is at the wire-protocol level. It implements PostgreSQL wire protocol v3.0 on port 7890, so psql and most Postgres drivers connect directly. A basic connection looks like this:
psql -h localhost -p 7890 -U postgres
No credentials are required by default, which is convenient for local trials and something to change before any real deployment.
Search lives inside SQL rather than behind a separate API. The @@ operator performs full-text matching with BM25 ranking, ts_phrase handles phrase queries, and vector search uses an ivf index with the <=> distance operator, so lexical recall and semantic ranking can run in one statement against one index. The ai_embed function generates embeddings from SQL, so an AI workload can embed, store, and retrieve without leaving the database.
It also leans into a zero-ETL story. SereneDB reads Parquet, CSV, and JSON directly, and it can index data in place on S3 or HDFS, including Parquet and Iceberg tables. Remote Postgres or ClickHouse tables can be queried through CREATE SERVER foreign servers. New rows become searchable at the next index refresh, every second by default, according to the official site. That freshness claim is what makes it plausible for log and observability use cases, where yesterday's data is not good enough.
Aspect | SereneDB | Elasticsearch | ClickHouse | Postgres |
|---|---|---|---|---|
Full-text search | Built in, first-class | Core strength | Weak, not its job | Basic, via extensions |
SQL analytics | Built in | Limited, via SQL plugins | Core strength | Core strength |
Postgres wire protocol | Yes, v3.0 on port 7890 | No | No | Native |
Vector search | Built in, same index | Via plugins and dense vectors | Via distance functions | Via pgvector |
Single-node production | Yes, since Krummelanke | Yes | Yes | Yes |
Distributed clustering | On roadmap, federation today | Mature | Mature | Via extensions |
The SearchBench Numbers, With a Caveat
SereneDB publishes its own benchmark, SearchBench: 92 search-and-analytics queries over OpenTelemetry logs at 100 million, 1 billion, and 10 billion rows, with a 60-second per-query cap, one node per engine, and result caches off. The methodology and adapters are published, which is better than a bare marketing claim, but the numbers below are still the vendor's own results, not an independent test.
On 1 billion logs, the official SearchBench write-up reports a hot median latency of 32.5 ms for SereneDB, with 92 of 92 queries finished and 112.1 GiB on disk, against 98.4 ms for Elasticsearch 9.5 (88 of 92 finished, 153.2 GiB), 195.2 ms for OpenSearch 3.8, and 543.5 ms for CrateDB 6.4. The test machine was a single GCP n2-standard-32 instance with 32 vCPUs and 128 GB of RAM. The homepage summarizes the same run as a geomean of 1.11x for SereneDB, versus 3.45x for Elasticsearch, 14.21x for ClickHouse, and 50.69x for Postgres, plus a load time of 5 minutes 10 seconds against 3 hours 19 minutes for Elasticsearch.
The README's headline claim of being 10 times faster than ClickHouse on 10 billion OpenTelemetry logs is in the same category: a company claim, repeated by press coverage, not an independently verified measurement. One encouraging detail from Tech Funding News is that ClickHouse's own team submitted benchmark changes that SereneDB folded into a retest, which is the closest thing to outside validation found so far. Treat the benchmark as a reason to try it on your own workload, not as proof.
Maturity and Limits
Krummelanke is production-ready for single-node deployments, but scale-out today works through federation, and full multi-node clustering is on the public roadmap for next year, with an enterprise edition covering clustering, high availability, and security expected in Q4, according to StartupRise and Blocks and Files. That frames the honest evaluation: if your workload fits on one large node, SereneDB is a real candidate today. If you need a distributed cluster with failover, it is not there yet, and the enterprise features around that are not open source.
Other limits worth noting: the project is barely a year old, with 836 commits and 39 releases, so its long-term stability record is short. And while the Postgres wire protocol covers most clients, wire compatibility is not the same as full Postgres compatibility, so Postgres-specific features and extensions should be tested, not assumed.
How to Try It
The quick start docs offer a single binary, an installer script, or Docker:
docker run -d --name serenedb -p 7890:7890 -e SERENEDB_HOST_AUTH_METHOD=trust serenedb/serenedb
From there, psql connects on port 7890, and you can load a Parquet file or point it at an S3 bucket and start running @@ search queries and analytical SQL against the same table. That one-command trial is the fastest way to judge whether the benchmark story holds up on your own data.
Frequently Asked Questions
Is SereneDB a fork of Postgres?
No. It is a separate engine that implements the PostgreSQL wire protocol v3.0, so Postgres clients connect to it, but it is not Postgres itself, and its search core is built on the IResearch information retrieval library.
Does it replace Elasticsearch, ClickHouse, and Postgres all at once?
Only for workloads where search and analytics hit the same data, such as logs and observability. It does not aim to replace Postgres as a transactional system, and its clustering story is not yet mature enough to replace a distributed Elasticsearch or ClickHouse deployment.
Is the whole thing open source?
The complete single-node version is Apache 2.0, and the company states it will stay that way. Clustering, high availability, and security features are planned for an enterprise edition.
How fresh is newly written data?
New rows become searchable at the next index refresh, every second by default, according to the official site. That makes it suitable for near-real-time log search, not for sub-second transactional reads.
SereneDB is a young project making a bold claim: that search and analytics belong in one engine, and that engine can speak Postgres. The benchmark numbers are promising but self-published, and the clustering roadmap is unfinished, so the right move is a trial on your own logs, not a migration on faith. If that trial holds up, one database doing two jobs is a genuinely simpler stack.