# SereneDB: search and analytics in one Postgres-compatible engine > SereneDB is a C++ database that puts full text search, vector search and column oriented analytics behind a Postgres compatible SQL layer, with retrieval handled by the open source IResearch library. It is aimed at teams that currently run a search cluster and an analytics database side by side and want one system instead. **serenedb/serenedb** — The First Real-Time Search Analytics Database - Repository: https://github.com/serenedb/serenedb - Website: https://serenedb.com - Stars: 952 · Forks: 73 - Language: C++ - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/serenedb-serenedb ## One engine instead of a search cluster beside an analytics store SereneDB is described as the first real-time search analytics database, and the README puts the pitch plainly: it unifies Elasticsearch-like search and ClickHouse-like analytics in a single, Postgres-compatible database. That combination answers a common architecture problem. Many teams end up with data in a columnar analytical store for reporting and the same events copied into a separate search index for full text queries, with two query languages, two backup plans and two failure modes. SereneDB's claim is that both workloads run against one copy of the data through one SQL dialect. The implementation is C++, and the layout of the repository shows a large codebase with a server directory, an `apps/` directory, a `packages/` directory, a `tests/` directory, `third_party/`, CMake files and presets, plus dedicated directories for `iresearch/` and `serene-ui/`. The presence of `serene-ui/` corresponds to the UI client the README lists as an intuitive Postgres-compatible UI for managing and querying data. The compatibility claim is the one to hold onto, because it is what makes the rest of the ecosystem apply: the README says you can leverage your existing Postgres ecosystem, tools and knowledge, and puts it plainly, if you know SQL you know SereneDB. ## IResearch is the retrieval engine, not a wrapper around Lucene Search is described as a first class citizen of the query engine, and the README states that all search functionality is powered by IResearch, an open-source C++ information retrieval library that core members of the SereneDB team have been developing since 2016. That detail separates SereneDB from the design of most search databases, which take an existing engine such as Lucene and put storage, distribution and a query layer around it. Here the retrieval library is in the same repository, under `iresearch/`, and is the component the README points to when it makes speed claims, saying IResearch outperforms Lucene, the engine behind Elasticsearch, across every query type in the Search Benchmark, the Game. The other search capability worth naming is vector and hybrid search, listed as built-in vector search and hybrid ranking for AI-powered applications. Combined with BM25 ranking, which the README mentions in the remote search feature, the engine covers lexical scoring, embeddings, and the two combined. The repository also shows where the project fits into the wider ecosystem. The README says the team builds on, contributes back to and openly collaborates with open source projects including Velox, PostgreSQL and RocksDB. ## Remote search without an ingestion pipeline The feature the README calls Zero-ETL Remote Search is the most distinctive capability. You can query data held in Parquet, Iceberg, CSV and JSON directly on remote storage on S3 or HDFS, with full BM25 ranking and vector search, and the README frames this as eliminating the need for expensive ingestion pipelines. The mechanism is worth understanding, because it changes what a search database is for. In a conventional setup, data lands in a local index and the index is what you query. Here the query can go to the files themselves on object storage, which means a dataset that arrived today can be searchable without a pipeline that copies it, transforms it and keeps a second copy in sync. The cost of that approach is not stated in the README. Queries against remote files involve network round trips, and the README does not document any caching layer, prefetch behaviour or latency figures for the remote path, nor how vector search indexes are built when the source is a file rather than a table. If your workload is interactive rather than batch, that gap is the first thing to probe. The `examples/` directory holds eight numbered demos, from `demo0` to `demo7`, plus a dedicated `examples/iresearch/` folder and an `examples/README.md`, which is the place to look for how these features are exercised in code. ## The benchmarks are open, and they are the project's own The README leads with benchmarks, and it is worth reading them carefully as claims by the vendor rather than as settled fact. The headline is a comparison claiming 10x faster than ClickHouse on 10 billion OpenTelemetry logs, with a link to a specific run in the project's own SearchBench tool. There is a second benchmark at 1 billion OpenTelemetry logs, linked to a playground instance. The README describes SearchBench as an open benchmark for search and analytics covering SereneDB, ClickHouse, Elastic, OpenSearch and ParadeDB, and separately describes Search Benchmark, the Game as a low-level search engine benchmark comparing IResearch, Lucene and Tantivy. Two things are going on. The first is a database level comparison against systems that do one of the two halves of the job, which is the comparison a buyer actually faces. The second is a component level comparison of the retrieval libraries, which is where the IResearch over Lucene claim comes from. The project states a philosophy point that matters for how to read them: all benchmarks are open and reproducible, and methodology, hardware and raw results are published alongside numbers. That is the right posture, and it is what makes the claims checkable. But the datasets are OpenTelemetry logs and the harnesses are hosted on the vendor's site, so a reader who wants to rely on this should run the same queries against their own data rather than adopt the headline figure. ## Building from source, because there is no documented install The README does not contain an install command, and it does not describe a packaged distribution. For build instructions it points to CONTRIBUTING.md, which it describes as covering build instructions, code style and how to get started. The repository layout supports that. There is a CMakeLists.txt and a CMakePresets.json at the top level, cmake/ and packages/ directories, a scripts/ directory, a server/ directory for the database process, an apps/ directory, and a tests/ directory. The build is therefore a source build with presets, and the practical detail about toolchain versions, dependencies and build options lives in CONTRIBUTING.md rather than in the README. The `examples/` folder is the low friction entry point for evaluating the project. Eight demos sit alongside a dedicated folder for IResearch examples and a README of their own, so you can compile the library and drive it from small programs without first assembling a server deployment. The C++ nature has an implication for evaluation. SereneDB is not something you install, point at a bucket and try in five minutes. The build itself, with a large C++ codebase, third party directories and CMake presets, is the first hurdle, and it is a larger one than the README's bullet points suggest. ## What the open source commitment does and does not cover The project's philosophy section is specific on one point: the complete, single-node version is and always will be licensed under Apache 2.0. The repository licence matches, and there is a NOTICE.md alongside the LICENSE file. Read that sentence carefully and it defines the boundary of what you get in the open source build. Single node is covered, permanently. The rest of the listed goals, horizontal scalability, high availability and advanced security for production deployments, sit outside that guarantee, which means they are the parts you either build yourself or source from the commercial offering. That is a normal open-core split, but it is worth pricing before you commit to running this in production. Two other limits are visible. The README says efficient real-time updates work through column-wise updates that keep data fresh without performance hits, which is a different update model from a row store, so application code written for Postgres semantics may need rethinking for write patterns. And the README's feature set is database level; there is no documented compatibility list for Postgres extensions or features, so the claim of compatibility is best verified against the specific features your application uses rather than assumed. Finally, the search comparison deserves a caveat. SereneDB positions itself against Elasticsearch, ClickHouse, OpenSearch and ParadeDB in the same benchmark. Those systems are not interchangeable with it, since each covers a different part of the workload, and a benchmark can favour one shape of query over another. Test with the queries you actually run. ## A release train, and a company behind it The tagged releases show a steady, frequent cadence: v26.09.1.2 on 2026-09-23, v26.09.1.3 on 2026-10-01 and v26.10.1 on 2026-10-05, with the last push on 2026-10-20. The version numbering follows the year and month, which makes it easy to see how recently a build was cut and makes upgrade planning a matter of date rather than semver ranges. The project is company backed rather than a solo effort, and that has consequences worth weighing. There is a commercial product behind the open source single node version, so roadmap priorities follow the company's customers, and the open source build is the one guaranteed to stay Apache 2.0 licensed. The README also lists a Slack, a Telegram channel and a Reddit community for support and discussion, plus a blog for technical articles and announcements. For a team considering adoption, that combination, an active release cadence, a published benchmark methodology, a permissive licence for the single node case and a company behind it, is a reasonable starting position. What it does not give you is a compatibility guarantee for the distributed deployment you may actually need, which is where the open source promise stops. ## Conclusion Adopt SereneDB when you are running a search cluster and an analytics store for the same data, you want one Postgres compatible SQL surface over both, and you are willing to evaluate the benchmark claims yourself on your own queries rather than take them on trust. Skip it if you need a multi node deployment today, since the Apache 2.0 commitment covers the complete single node version, or if you need a packaged install, because the README does not document one and points to CONTRIBUTING.md for build instructions. Verify first that IResearch handles your query types, since the README's speed claims over Lucene rest on that library. The last push was on 2026-10-20, with tagged releases v26.09.1.2, v26.09.1.3 and v26.10.1 in September and October 2026. ## FAQ ### What is SereneDB and who is it for? SereneDB is a C++ database that unifies Elasticsearch-like search with ClickHouse-like analytics in a single Postgres-compatible database, with full text, vector and hybrid search. It is aimed at teams that would otherwise run a search cluster and an analytical store over the same data. ### What search engine does SereneDB use internally? All search functionality is powered by IResearch, an open-source C++ information retrieval library that core members of the SereneDB team have been developing since 2016, and which lives in the `iresearch/` directory of the repository. ### Can SereneDB query data directly on S3 or HDFS? The README describes a Zero-ETL Remote Search feature that queries Parquet, Iceberg, CSV and JSON data directly on remote storage on S3 or HDFS with full BM25 ranking and vector search, eliminating the need for expensive ingestion pipelines. ### How do I build SereneDB from source? The README does not document an install command and points to CONTRIBUTING.md for build instructions, code style and how to get started. The repository contains a CMakeLists.txt, CMakePresets.json, cmake, packages, scripts, server and tests directories, and an examples folder with demos from demo0 to demo7. ### What licence does SereneDB use and what does it cover? The licence field on the repository says Apache 2.0, and the README states that the complete, single-node version is and always will be licensed under Apache 2.0. Horizontal scalability, high availability and advanced security for production deployments are listed among the project's goals rather than as open source guarantees. ### How often is SereneDB released? The tagged releases are dated by year and month, with v26.09.1.2 on 2026-09-23, v26.09.1.3 on 2026-10-01 and v26.10.1 on 2026-10-05. The last push was on 2026-10-20. ## Sources - [License: Apache-2.0](https://github.com/serenedb/serenedb/blob/main/LICENSE) - [Project website](https://serenedb.com) - [README](https://github.com/serenedb/serenedb/blob/main/README.md) - [Releases](https://github.com/serenedb/serenedb/releases) - [serenedb/serenedb on GitHub](https://github.com/serenedb/serenedb) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/serenedb-serenedb