Originally published on https://mnt.cr/go/wx99Cf on September 15, 2026

How Bookbot powers 3.5 million saved searches and ~10% of revenue with Manticore Search

How Bookbot uses Manticore Search to keep 1.29 million second-hand books searchable, match new arrivals against 3.5 million saved searches, and power a channel responsible for ~10% of revenue.

For a second-hand bookstore, search has to do more than find a title. It has to find a copy that actually exists.

Bookbot, known as Knihobot in the Czech Republic, takes in used books, photographs them, catalogs them, sells them, and ships them to their next readers. Two copies of the same title may have different editions, prices, conditions, and photographs. When one copy sells, the search result may need to change immediately-even if the title itself remains available.

Bookbot uses Manticore Search to keep this constantly changing inventory searchable. Its main book index contains around 5.3 million documents, including approximately 1.29 million physical copies currently in stock. Manticore also stores around 3.5 million saved-search queries for Bookbot's Watchdog feature.

According to Bookbot's internal figures, Watchdogs account for roughly 10% of revenue.

Bookbot co-founder and CTO David Gazdoš shared how the company uses Manticore not only to power customer search, but also to keep search results aligned with physical inventory, choose the right copy to show, match newly available books with waiting readers, search a 203-million-record bibliographic dataset, and support internal operations.

When every copy is different

A conventional online store can often represent a product with one record and a stock counter.

Bookbot's inventory is different. A title can have several editions, and each edition can have many individual physical copies. Those copies can differ in price and condition, and each has its own photograph and availability.

That means a Bookbot search result cannot simply say, "we have this title." It needs to represent an offer the customer can actually buy.

Imagine that the copy currently shown for a title costs €6. That copy sells, but another copy of the same title is still available for €9.

The title can remain in the results, but the offer needs to change: new price, new photograph, and potentially a different edition. If the customer filtered for books below €8, the title should disappear from that result set altogether.

This is where Manticore's real-time tables are important.

MySQL remains the source of truth for Bookbot's business data. Kafka carries events generated by orders, reservations, price changes, lost or discarded books, temporary withdrawals, and catalogue corrections. As the application processes those events, it can replace, update, or remove individual records in Manticore.

Instead of treating search as a periodically rebuilt copy of the catalogue, Bookbot can keep the searchable offer aligned with what is happening to the physical books.

“Manticore lets us update the searchable offer as the physical inventory changes. When one copy sells, we can replace or remove that record without rebuilding the whole index.”

For the customer, the benefit is simple: the price, edition, condition, photograph, and availability shown by search continue to describe something they can actually buy.

One title in the results, many physical copies underneath

Keeping the inventory fresh solves only half of the problem.

Customers normally want to browse titles, not dozens of nearly identical copies of the same book. But Bookbot still needs to preserve the differences between those copies underneath.

Manticore's grouping lets Bookbot bridge those two levels.

The application first filters the physical copies that satisfy the customer's request. It then groups the remaining records by title and uses WITHIN GROUP ORDER BY to choose which copy should represent that title in the result set.

The order matters.

Suppose a title has copies from different publishers at €6, €9, and €14. A customer asks for Publisher B, a price below €10, and no recorded damage. The result needs to be a physical copy that satisfies all three conditions at once.

Bookbot cannot take the publisher from one copy, the price from another, and the condition or photograph from a third. That would describe an offer that does not exist.

Manticore lets the filters operate on the underlying copy-level records before the matches are grouped. The representative copy can then be selected according to the requested ordering. Sorting by price may pick one copy; sorting by publication year may pick a different edition.

“Manticore gives us the copy-level precision we need while still letting us present one clean result per title. The filters apply to the real physical copies first, so the result always represents an offer we can actually sell.”

When that representative copy sells, another suitable copy can take its place.

The same principle applies to facets. Bookbot counts distinct titles rather than raw physical copies, so a title with hundreds of copies does not dominate a category simply because more of it happens to be in stock.

For browsing requests that can safely be answered at title level, Bookbot maintains a smaller precomputed index with about 3.59 million title records. When a query requires copy-level correctness-such as full-text search or filters that must all match the same physical item-the application uses the full book index instead.

This gives Bookbot both sides of the tradeoff: a faster path where title-level data is sufficient, and copy-level precision where it is not.

Turning unavailable books into future demand

The most interesting use of Manticore at Bookbot begins when there is nothing to sell.

Second-hand inventory is unpredictable. A reader may know exactly which book or edition they want while Bookbot has no suitable copy available.

Instead of making that reader come back and repeat the search every few days, Bookbot lets them create a Watchdog. It can track a title, author, genre, edition, price, or a more detailed combination of criteria and notify the reader when a matching book appears.

This reverses the normal direction of search.

With ordinary search:

one query → matching books

With a Watchdog:

one newly available book → matching saved queries

Manticore's percolate tables are built for this "search in reverse" pattern. Instead of storing documents and running a query against them, Bookbot stores the queries and submits a book to find which saved searches it matches.

At the time of Bookbot's production snapshot, Manticore held around 3.5 million Watchdog rules.

When a pricing event makes a book available, the application sends its searchable representation for percolate matching. Manticore returns the matching saved searches. Bookbot then applies its own business logic: whether a Watchdog is still active, whether the customer is eligible for a notification, and whether the match should be sent immediately or included in a digest.

Manticore handles the matching; Bookbot controls the customer experience around it.

This turns search into something more valuable than a way to browse current inventory. It becomes a way to preserve demand when supply is missing and reconnect that demand with a future copy.

According to Bookbot, Watchdogs account for around 10% of revenue.

“Manticore lets us match each newly available book against around 3.5 million saved searches. Watchdogs now account for roughly 10% of our revenue, so this is not just a search feature-it has become an important business channel for us.”

For Bookbot, this is a direct business result of being able to search in both directions: readers can search the catalogue, and newly available books can search for readers who already want them.

The same pattern can apply far beyond books-to back-in-stock alerts, classified listings, jobs, property, tickets, price alerts, or any product where new supply needs to be matched with previously expressed intent.

Search that helps readers even when they do not type perfectly

Book search also has a relevance problem: people do not always remember titles, author names, translations, or series exactly as they appear in the catalogue.

Bookbot uses a dedicated Manticore dictionary with roughly 4.52 million edition records for typo correction. It includes titles, authors, series, aliases, curated misspellings, localized fields, and German transliteration variants, while excluding identifiers such as ISBNs from correction candidates.

The dictionary proposes possible editions, but it does not decide what Bookbot can sell. The main inventory index still determines which physical copies are currently available and satisfy the user's filters.

This separation is useful because the two datasets have different jobs and different freshness requirements. The typo-correction dictionary can be refreshed on its own schedule, while the main inventory index follows live availability.

For readers, the result is more forgiving search without sacrificing the correctness of the actual offer.

One search engine across the life of a book

Customer search and Watchdogs are the clearest user-facing examples, but Bookbot uses Manticore in several other parts of the business.

Before a physical book can appear in the store, Bookbot needs to identify and catalogue it. A separate bibliographic metadata pool contains approximately 203.44 million reference records searchable by ISBN, title, and author.

Text such as titles, authors, and annotations remains full-text searchable, while structured metadata such as ISBN, publisher, publication year, language, and category IDs uses Manticore's columnar storage.

Internal search also runs on Manticore. Bookbot's backoffice indexes cover books, editions, authors, customers, orders, and accounting records; the internal book index used by pricing and lookup workflows contains about 24.7 million records.

Search extends into delivery as well. Another index contains approximately 197,000 pickup points, combining text lookup with geographic filtering and distance ordering using Manticore's geo-search capabilities.

This breadth matters because Bookbot develops its technology in-house. The team can reuse the same search engine for several very different workloads instead of treating customer search, reverse matching, large metadata lookup, internal search, and geo search as completely separate technical problems.

Manticore becomes part of the path a book follows through the business: identifying it, making it searchable, selecting the right physical copy, matching it with waiting readers, helping employees work with it, and finding a pickup point after it is sold.

“We use Manticore for storefront search, Watchdogs, a 203-million-record bibliographic dataset, internal search, and pickup-point lookup. Reusing the same search technology across these workloads keeps the architecture much simpler for our team.”

Production scale with a compact footprint

Bookbot runs four separate Manticore workloads on Kubernetes: customer search, backoffice search, Watchdogs, and the bibliographic metadata pool. They run on separate servers so each workload can be sized independently.

A production snapshot from September 5, 2026 looked like this:

The query-volume figure is a count of instrumented Manticore operations, not human searches. A single page request can issue several operations for results, item selection, and facets.

Likewise, the 7.7 ms measurement covers the application's Manticore call for successful item-selection queries; it is not complete page-load time or end-to-end inventory-update latency.

Across the four workloads, Bookbot observed no sustained CPU or memory saturation during the measured period. Customer-facing search used most of the CPU, while the 203-million-record metadata workload used less than 0.1 CPU core on average and about 18.6 GiB of memory.

The important point is not any single benchmark number. It is that Bookbot is using one search technology across live ecommerce search, reverse matching of millions of saved queries, a 203-million-record reference dataset, internal operations, and geo search-while keeping the infrastructure relatively compact.

Search that follows the life of a physical book

Bookbot's use of Manticore is unusual because search is closely tied to the lifecycle of each physical item.

A book arrives. Metadata search helps identify it. A real-time update makes the copy searchable. Filters make sure its price, edition, condition, and photograph stay together. Grouping gives the title one place in the results while selecting a real purchasable copy.

If no copy is available, a reader can leave a Watchdog behind. When another copy enters the system, Manticore can match that book against millions of saved searches and help Bookbot reconnect new supply with existing demand.

When the copy sells, search changes with the inventory and another suitable copy can take its place.

For readers, that means search that reflects what is actually available and remembers what they want when it is not.

For Bookbot, it means search contributes at several points in the customer journey-and, through Watchdogs, to a channel the company says generates roughly 10% of its revenue.

That is the value Manticore brings here: not simply finding text quickly, but giving Bookbot one search platform for fast-changing inventory, structured filters, grouped results, reverse search, large reference datasets, and geo search - and turning those capabilities into a better buying experience and measurable business value.