SereneDB

Ultra-Fast Search & Analytics Database, Agentic AI ready

Open Source

Developer Tools

GitHub

Database

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

Congrats on the launch. We run a RAG platform where every answer has to link back to a specific passage, so the "one engine for full-text and analytics" pitch is interesting to me for a practical reason: the ETL hop between the search index and the analytics store is usually where our provenance metadata gets lost. Question for the team: when you return a hit, how much of the original document position (page, offset, section) survives into the result, and is that queryable alongside the analytics side? That's the thing that would decide whether we could put this under a citation layer.

Congrats! Giving this enterprise-level product away for free is a big deal! I wonder if there are enough large open datasets to even use it to its full capacity?

Important technology to be working on. As AI agents expand traffic at a huge rate, database bottlenecks will be production issues you can't prompt your way out of. Cool stuff

Love that you unified full-text search and analytics into one Postgres and Elastic compatible engine, letting teams drop a whole layer of infra while staying ready for agentic query loads.

the "100 AI agents per human user, hundreds of queries a second" framing in your slide is the part I'd want to stress test, since that's a completely different access pattern than the one-analyst-at-a-dashboard load most search/analytics engines were tuned for. is the ~10x disk and speed advantage measured under that kind of high-concurrency, many-small-queries load, or is the benchmark closer to a traditional single-client full-text/analytics workload? and on the "Postgres-compatible, keep your drivers" claim, how deep does that compatibility go, is it wire-protocol plus the SQL surface people actually use day to day, or are there specific extensions/features people migrating off real Postgres deployments tend to hit first?

What is the downside to saving 10x the disk space compared to Elasticsearch? Is it a matter of query latency or just storage efficiency?
Additionally, Congratulations @malandin and @gnusi ✌️🎊✌️

Hey everyone, I’m Andrey, CTO of SereneDB.

I’ve been building search engines since 2012, and today we’re launching the first production-ready release of SereneDB—the engine I’ve spent over a decade wanting to build. It delivers sub-second full-text search and fast columnar analytics over billions of records in a single engine. It’s open source, Postgres-compatible, light on infrastructure costs, and straightforward enough for a solo builder with a coding assistant to deploy in an afternoon.

Back in 2012, I was building log storage at Quest Software. After spending a month failing with every relational trick in the book, I gave Lucene a try. A crude prototype answered in milliseconds what had been taking seconds. That was the moment I fell into search, and I never climbed out.

Later at EMC, I pitched and built a search project, co-authored a patent, and fought through a six-month corporate saga to get the engine open-sourced. Over the years that followed, I helped grow that prototype into distributed systems running in production at petabyte-scale enterprises.

Along the way, something bothered me more with every passing year: search stopped moving. Analytical databases got vectorized execution, cost-based optimizers, and decades of academic research. Search engines, on the other hand, still intersect posting lists the exact same way they did when I started. The industry started treating one product's limitations from 2012 as laws of nature.

SereneDB is what happens when you refuse to accept that. We took the execution mechanics of modern analytical databases—optimizer, physical plan, scoring, all of it—and fused them directly with columnar analytics inside one Postgres-compatible box. The index sits over data on object storage, so your hot working set stays small and your cloud bill stays minimal.

We benchmark everything in the open at serenedb.com/searchbench. Same machine, one instance per engine, 92 search-and-analytics queries, a 60-second cap, and every config and raw result made public.

A few highlights from the board:
Postgres: Couldn't return 63 out of 92 queries at 100 million records
Elasticsearch: At 1 billion records, its best configuration (out of four) averages about 3x behind us.

ClickHouse: At 10 billion records, ClickHouse—which is truly the best column store out there—can't run the 22 relevance-ranked queries at all and times out on 22 more. It beats us on 8, and our write-up breaks down exactly where and why.

Ask me anything about the architecture, execution engine, or benchmarks—I'll go as deep into the technical weeds as you'd like.

Hi Product Hunt! Alexander here, co-founder and CEO of SereneDB.

Andrey and I have known each other for about seventeen years. We met as junior techs sharing a tiny office. We always knew we would build something together; it just took us two decades to find the thing.

I found it by helping people choose and implement databases. For years my job was to solve customers' data problems, and I kept noticing something strange: whatever problem walked through the door, the search engine Andrey had built solved it better and faster than the tools designed for it. Not sometimes. Consistently. I wasn't a believer because he's my friend -- I was a believer because I saw it working in production.

The more I worked with search as a technology, the clearer the bigger picture became. Our industry's idea of what search can do froze close to a decade ago. Everyone hit the same limits set by existing search vendors, built their architectures around these limits, and stopped asking. Meanwhile the technology kept moving, to the point where people now refuse to believe what they see in demos.

So we built SereneDB: search and analytics fused in one open-source, Postgres-compatible engine. Our first build-server was assembled in Andrey's apartment -- he paced the room while I turned the screws. Today we're launching Krummelanke, the first named release. Pull it from GitHub and run it.

One more thing, because I know you will ask. We say it's the fastest search and analytical database on the market, and we know how that sounds. So we have the open-sourced proof: SearchBench, 92 real queries over 100 million, a billion and 10 billion records, every engine tuned with public configs, every result on a live board. Elasticsearch, OpenSearch, ClickHouse, the Postgres search extensions, vanilla Postgres. If you think a config is unfair, file a PR and we'll rerun it.

Ask us anything -- we answer everything, including the uncomfortable questions.