Launched this week
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.
Glam AI
Impressive. Good luck, team!!
InterSub
@kristina__grits Thank you!
superlog
amazing product! congrats on the launch!
@arseniy_shishaev1 Thank you!
Naoma AI Demo Agent
InterSub
@dmitry_zakharov_ai Thank you!
Macaly
search + analytics in one engine and no ETL in between, love it 🔥 how painfull is moving off elastic?
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?
@galdayan Thank you for bringing this up!
On the benchmark
SearchBench is single-client: one query at a time, three tries each (cold, hot, hot), with an engine restart and cache drop between queries. It measures isolated latency, not throughput under concurrency. The latency number indeed might require a dedicated benchmark, but my expectation is that agent traffic is actually good for us. It's mostly filtered top-K and point lookups, the exact sweet spot for the search index and a fleet of agents keeps the working set hot where the benchmark deliberately keeps it cold. The real risks are per-connection memory at high connection counts and contention between reads and live ingest.
We don't have the number you're asking for yet. We'll be adding a concurrency mode to SearchBench: N clients, QPS, p50/p95/p99 under load but more likely with less versatile queries.
On Postgres compatibility
It's both pg-wire and Postgres SQL. For testing and development we use vanilla psql, psycopg3, JDBC, pgrust and others. SereneDB doesn't share Postgres's codebase, but some functions were taken and rewritten to preserve Postgres semantics. That's why extensions don't work and PL/pgSQL isn't yet supported, but we use a compatible DDL to provide the same functionality. Most of pg_catalog is covered. We have a dedicated page https://serenedb.com/docs/compatibility/core-sql-compatibility for tracking our core sql and postgres compatibility and we keep this page up to date.
In general, we don't pitch it as a Postgres replacement, our goal is to become an easy way to get Elasticsearch or ClickHouse functionality sitting next to your original Postgres with one query language and one driver stack.
Hope it makes sense!
Dial
that's a genuinely useful distinction, thanks. makes sense that agent traffic would skew toward the hot-cache case rather than the cold-restart benchmark scenario. curious to see the N-client QPS numbers once that concurrency mode lands, especially at the point where per-connection memory starts competing with live ingest. and appreciate the honesty on not pitching this as a drop-in Postgres replacement, that's the kind of thing that saves people a bad migration later.
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.
@ilko_kacharov Great that you like it!