Viktor.comAn AI coworker that actually does the work
Promoted
Launching today
SereneDB is the result of 12 years of development - an open-source database that does ultra-fast full-text and fast analytics in one engine. Postgres- and Elastic-compatible: keep your SQL, your drivers, and your Elastic clients; drop the second system and the ETL between them. In our public benchmark, it outperforms Elasticsearch, ClickHouse, and Postgres search extensions, and indexes 1B logs in under 8 minutes at ~10x less disk. Apache 2.0, methodology, and raw results are public.
InterSub
SereneDB built something that is usually available only to big-wallet vendors: a database that holds a huge amount of data in one node, on an ordinary machine, and does ultra-fast search plus analytics at an enterprise level. Their full-text search is the fastest today, based on benchmarks anyone can verify.
And all this -- open source!
I have a Master's in CS, but it was a long time ago, and I completely forgot how to code. I still remember the fundamentals of how to build software, though. This era of vibecoding is my renaissance: I use AI to build what I have wanted to create for a long time. One component was missing -- an easy-to-use database. Yes, there is Postgres, but you need real skills to set it up and tune it. With SereneDB I just paste the line into Claude Code, connect the docs MCP, and work (I had to install Docker along the way, though).
Now I have almost no limit on data volume: these are enterprise-level datasets I can search and analyze on ordinary virtual machines.
Imagine how much freedom that gives to scientists all over the world: all of PubMed's 37 million abstracts, NOAA's daily climate records from 100,000+ stations, every photo NASA's Mars rovers have ever sent back -- searchable and analyzable on an ordinary VM, by one person with a coding assistant. And imagine how many more use cases they will come up with by pairing their AI coding assistants with SereneDB.
I'm proud to be the team's hunter. They see the future, and they built the missing component for it: a vibecoder-friendly, top-level database.
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.
@malandin How does SereneDB compare with Elasticsearch on really large production workloads ?
@dipanshu_kushwaha5 thanks for this question! We have compared ourselves with Elasticsearch on 1B log entries and saw a lot of efficiencies. Have a look here, please: https://serenedb.com/searchbench. On the other hand, if you are asking about petabytes of data, we support this in federated deployments now and working on releasing clustered system in the coming year.
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 ✌️🎊✌️
Thank you @aymi_malik! Apparently, there's no downsides. On the contrary, there's a huge upside on performance. Once everything is compressed, retrieving from storage to RAM takes less and this greatly increase the overall performance. The benchmark at serenedb.com/searchbench shows it but it isn't the only place we talk about it. If you are interested, this part is covered in the `Search Benchmark, The Game` story here: Adaptive Posting Lists
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.
Govar – English speaking app
Good luck with the launch. Cool product
Thank you @dzianis_yatsenka! It means a lot to us!
Naoma AI Demo Agent
InterSub
@dmitry_zakharov_ai Thank you!
Dial
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?