When you ask an AI agent a question, it may seem like a simple request. Behind the scenes, however, the agent may run several searches, then issue more queries to analyse what it finds. For businesses using separate systems for search and analytics, that extra work can add cost and complexity.

SereneDB has built its answer around a database that handles search and analytics together. In September 2026, it launched Krummelanke, which the company describes as the first production-ready version of its open-source real-time search analytics database. The company raised a $2.1 million pre-seed round in December 2025. Co-founder and CEO Alexander Malandin calls the wider AI industry an elephant standing on porcelain legs, with ambitious systems resting on data infrastructure built for an earlier kind of workload.

AI is blurring the line between search and analytics

Search engines and analytical databases evolved separately. Search products find relevant material in documents, logs and other unstructured data. Analytical databases calculate, join and identify patterns across structured records. Businesses that need both often connect them by copying data between systems and keeping it synchronised.

Natural-language interfaces can multiply the number of searches before any analysis begins. In a demonstration discussed with SereneDB, ESG reporting platform Karomia showed how one human request could turn into several shorter database searches. The example illustrates how quickly an apparently simple interaction can increase the work beneath the interface.

The workload can rise well before autonomous agents become commonplace. Every user request that generates several database operations adds to the strain. If agents begin working more independently and in parallel, query volumes could grow with software activity rather than staff numbers. The pressure on separate systems would grow with them.

What SereneDB changes

SereneDB puts full-text and vector search together with analytical execution in one engine. It is licensed under Apache 2.0 and speaks PostgreSQL's wire protocol. It also supports a documented subset of the Elasticsearch REST API. Many existing tools can therefore connect while customers test whether one engine can replace separate systems for search and analysis.

SereneDB's tiered-storage model keeps frequently used data in a small local working set while the rest remains searchable in open formats in cloud object storage, including Amazon S3. Keeping that data searchable in place could reduce the need to create another complete copy for each new workload.

Many enterprises already hold the same information in a data lake and one or more specialist systems. They pay to store each copy, move the data and keep everything in sync. Indexing existing files can remove some of that duplication. SereneDB can build a search index over those files without moving the underlying rows into a second database. Teams can keep selected fields near the index for quick results and fetch fuller records from the source when needed. The economic case still depends on search remaining responsive when much of the underlying data sits in cheaper remote storage.

SereneDB publishes the configurations and methods behind its benchmark comparisons with competing search and analytics systems. Its SearchBench tests use 92 queries over OpenTelemetry logs and report ingest time, index size and query latency at different data scales. The scripts and raw results are public, giving prospective customers a way to examine its claims and test the engine against their own workloads.

Early users put the approach to work

Two early customers illustrate the problems SereneDB is designed to address. Boring Tax says it struggled to make lexical and vector search work reliably in production. The tax software company now keeps its document chunks and embeddings in Apache Iceberg tables on Amazon S3, with SereneDB providing the search layer above them.

Karomia says moving its data into open formats on S3 cut the RAM and disk needed for search while improving speed and quality. Along with Boring Tax's deployment, its account shows another reason to make data searchable where it is already stored instead of building and maintaining another copy.

From product launch to wider adoption

The open-source licence and familiar interfaces give teams a practical way to test SereneDB. Many PostgreSQL clients and Elasticsearch tools can stay in place during a trial, provided the operations they use are supported. Teams can then check their own queries and workflows without replacing every tool first.

SereneDB competes with established database and search vendors and other open-source projects. It supports scale-out through federation today, while full multi-node compute over an elastic storage layer remains on its public roadmap for next year. The current release offers a route to search and analyse data through one engine, using clients and workflows many teams know.

AI is likely to increase the volume and variety of database work, making the cost of duplicating data between search and analytics harder to ignore. SereneDB has shipped an engine that brings them together, published methods for testing its performance and secured early customer deployments. Those give organisations concrete starting points for weighing one system against the cost of running two.