Search Stopped Moving Around 2010. The Agents Are Not Going To Wait For It To Start Again

SereneDB’s first named production release is a bet that the forty-year split between finding data and counting it was an accident of history, not a law of computer science.

Underneath nearly every search box in the enterprise sits a Java library first released in 1999. Lucene is good software. It is also the foundation of Elasticsearch, OpenSearch and Solr, which means that for most of the industry, the properties of Lucene and the properties of search itself became the same thing somewhere around 2010. Engineers stopped describing its constraints as constraints. They described them as how search works: no real aggregations, no joins, no patch updates, data that becomes visible when it feels like becoming visible.

While that was happening, the analytical database world had two decades of a completely different experience. Vectorised execution. Cost-based optimisers that actually reorder your query. Columnar formats that compress a terabyte into something you can scan without a budget meeting. The gap between the two traditions widened every year, and the industry’s response was to run both and connect them with pipelines.

That is the architecture almost everyone reading this is paying for right now. A search cluster that can find things but cannot count them. A warehouse that can count things but cannot find them. Between the two, a set of sync jobs someone wrote in 2021 that nobody has volunteered to own since. Two copies of the data, the searchable one living on the most expensive storage the company rents. Two invoices.

The reason this survived so long is that humans are slow, and slowness hides a lot of sin. A person types a question, waits, reads, thinks, asks a better one. The four hundred milliseconds it took to hop between systems disappeared into the pause where the person was deciding what they meant. Every fragmented data architecture in production is subsidised by human hesitation.

That subsidy is being withdrawn. An AI agent does not hesitate. It fires queries in a loop, hundreds per second, and it never works alone. Jensen Huang told GTC in March that he expects Nvidia to be running with around 75,000 employees and seven and a half million agents within a decade. Whatever discount you want to apply to a chief executive’s projection, the direction is not seriously disputed: the heaviest consumer of company data is about to stop being a person. When query volume tracks agent count rather than headcount, every hop between systems stops being an inconvenience and becomes a line item multiplied by a very large number.

This is the context for what SereneDB released on 22 September. The Berlin company, which raised $2.1M in pre-seed funding last December, shipped Krummelanke, the first production-ready version of its engine, open source under Apache 2.0. The claim is that full-text search, vector search and analytics belong in one query plan over one copy of the data, and that the forty-year split between the two disciplines was an accident of history rather than a law of computer science.

Plenty of companies have made a version of that claim. This team has been making it for a decade. Andrey Abramov and Valery Mironov wrote IResearch, a C++ search library built as an alternative to Lucene, and then spent seven years doing the thing almost nobody else attempted: putting it inside a database rather than beside one. That became ArangoSearch, and it ran in production at enterprise customers including major banks. ArangoDB reached the DB-Engines top 10 in that period. Whatever else you think of the architecture, it was the first serious demonstration that search does not have to live in its own cluster with its own copy of the data. SereneDB is the second attempt at the same idea, by the same people, without the constraints of a graph database wrapped around it.

Running analytics over cheap object storage is settled technology. Running search over it is not, and that is precisely what SereneDB says it solved: the hot set stays on a small local working set, everything else sits on S3 and remains fully searchable through the same interface. If that holds under other people’s workloads, it changes the shape of the bill rather than the size of the discount. The company cites a design partner whose infrastructure went from roughly $2,500 a month to about a tenth of that. For an early-stage company, the difference between those two numbers is measured in months of runway.

There is a second thing this team does that I would like to see become normal. They publish the benchmark methodology, the configurations and the hardware, across the dozen most widely used engines, and they tell you to rerun it yourself. Their CTO’s line on it is blunt: don’t take our word for it, run them. Anyone who has sat through a vendor briefing where the comparison chart arrives without the config file knows how rare that is. Whether or not SereneDB turns out to be the fastest engine on the market in two years, the industry would be healthier if everyone had to show their work this way.

The honest caveats are the obvious ones. This is eight engineers and $2.1M against Elastic’s revenue and ClickHouse’s momentum. Multi-node clustering is on the roadmap rather than in the release; scale-out today runs through federation. A production-ready label from a company nine months out from its first funding is a statement of intent as much as a statement of maturity, and the people who find the sharp edges will be the first hundred teams to put it under real load.

But the part that will matter longest has nothing to do with whether this particular company wins. Underneath the release is a bet that the next generation of data applications will be built by people who are not database engineers: the scientist with a decade of papers to search, the analyst whose data outgrew the spreadsheet years ago, the founder whose coding agent can now write the application but has nowhere sensible to put the billions of rows underneath it. Those people were locked out by the data layer, not by the code. SereneDB’s own proof point is a frontend developer who built a complete search-and-analytics product over tens of millions of records in a fortnight.

Every few years the industry retires an assumption it had stopped examining. The assumption up for retirement now is that finding things and counting things are two different businesses. Agents will not tolerate it, the economics no longer justify it, and somebody was always going to build the engine that ends it. A team in Berlin has just put theirs on GitHub and invited everyone to try to beat the numbers.