What you need to know
- Krummelanke combines search and analytics; broader compute and storage separation remains a roadmap item.
- Define acceptable freshness and account for work sent back to remote data sources.
- Use public benchmark methods as a starting point, then check result correctness for the intended application.
One engine for finding records and computing over them
SereneDB is pitching a combined search and analytical database for applications increasingly queried by AI agents. Its Krummelanke release, announced on September 22, is available under the Apache 2.0 license. The company describes a Postgres-compatible engine that puts retrieval and computation in one query plan. It identifies federation as its current scale-out approach, while full separation of multi-node compute and storage remains on its roadmap for 2027.
The attraction is understandable: a service agent might need to find incident reports describing a particular symptom, then group the matching records by product version. A database that can handle both operations could reduce the application work between them. The purchasing question is how that arrangement behaves with the organization’s actual records and traffic.
Decide which values stay local
The company’s engineering walkthrough describes indexes over tables held in Postgres or ClickHouse. The index can retain selected column values locally; values left out are fetched from the original system when requested. That creates a choice between keeping more information beside the index and making additional trips to the source.
For a support application, that choice might separate a rarely changed product description from a frequently revised service status. Write down which value the answer must reflect and how old it may be. A fast text match alone does not establish that every field used in the final response meets that requirement.
Count the work at the source as well
SereneDB describes remote row retrieval in keyed batches after local matching. It also explains that an index can lag behind changes to the searchable material. Keeping a value in the original database and making a new record searchable are different parts of the process.
A useful capacity exercise would follow a complete support request: search, fetch the fields needed for the answer, then repeat after a record changes. Measure the calls reaching each system, not just the time reported by the search engine. Add concurrent requests and agreed failure cases, such as an unavailable source. This would test whether combining operations removes a bottleneck or moves it to a dependency.
Give correctness a place beside speed
SereneDB publishes SearchBench, an open benchmark with 92 queries spanning search, aggregation and joins over log-shaped data. Its README documents cold and warm runs, client round-trip timing and the machine configuration. It also explicitly states that the benchmark does not validate correctness across engines.
Those materials offer a starting point for inspecting a performance claim. A buyer’s evaluation should additionally compare returned records, totals and ordering against expected answers. Include the organization’s own permission boundaries and changing data. A result that arrives quickly is useful only if the application can rely on what it says.
