In a SaaS platform that customers configure with low-code/no-code tools, it is difficult to know in advance exactly what data users will want to search. One customer adds their own fields and forms, another configures custom business processes, and a third uses the data they find for filtering, bulk editing, or marketing campaigns.
Kiva Teknoloji faced exactly this challenge. The Turkish company has been developing cloud business applications since 2009. Its main product, KivaCRM, is built on the company's own Kiva Cloud Platform and combines CRM with tools for business process automation, reporting, and analytics. Customers can configure forms, lists, processes, reports, and dashboards themselves, so the same platform is used by companies across more than 40 industries.
That flexibility directly affects search. Every Kiva customer has their own database, and the table structure changes as they configure the application around their own processes. This means search cannot be configured once for a fixed set of fields and then left unchanged.
Manticore Search works here as a separate search layer alongside MySQL. It handles full-text search, while MySQL remains the primary database. This approach has allowed Kiva to reduce the load on its main database servers, add more flexible search capabilities, and do so with almost no increase in infrastructure costs.
Search is part of the platform, not just a search box
Kiva indexes all kinds of data that customers create in their applications. Search is available in different parts of the product, and the records it finds are used for more than just viewing.
According to Arda Beyazoglu , Lead Engineer at Kiva Teknoloji, search is used for analytics, filtering, bulk record editing, email and SMS campaigns, and other tasks.
"We use Manticore for full-text search and index all kinds of data generated by our customers."
This is not a typical catalog search with a predefined schema. Every Kiva customer has a separate database, and its structure depends on how the application is configured. As customers customize it, new fields and entities appear.
So the search layer has to adapt to each customer's data rather than to a single predefined model.
Why MySQL full-text search was not enough
Before moving to Manticore, Kiva used MySQL's built-in full-text search.
According to Arda, it was slower than Manticore and consumed resources on the main database server. That matters in a SaaS environment: the application itself needs the same CPU and memory, so search starts competing with its primary workload.
Kiva therefore moved full-text search into a separate layer instead of making MySQL handle both the main application workload and search.
MySQL remained the primary data store, while Manticore took over search.
Why Kiva moved to Manticore
Before Manticore, the team used Sphinx for some time. Kiva later moved to Manticore because of version compatibility issues and the slower pace of development of the previous solution. The team was still able to keep its existing search architecture.
A separate search table for every customer
The architecture now looks like this:
customer MySQL → search cache → periodically rebuilt table + RT table → Manticore distributed table → search → record IDs → MySQL
For every table containing customer data, Kiva generates a search cache. It then creates a separate Manticore distributed table for each customer.
It combines two local tables:
- one is fully rebuilt once a week;
- real-time changes go into an RT table .
This lets users search up-to-date data without Kiva having to constantly rebuild the entire search table.
When a user searches in the application, Manticore finds the matching records. The application then performs point lookups in the source MySQL tables to retrieve the rest of the data.
This avoids duplicating the full contents of the source tables in Manticore. Search only needs to return the IDs of matching records, while the application retrieves the rest of the data from MySQL.
Each system therefore has a clear role:
- MySQL stores the application's source data;
- Manticore handles search;
- the application uses IDs to connect search results back to the source records.
No dedicated search servers required
The amount of data varies significantly between Kiva customers: the platform is used by both small businesses and large enterprises.
Arda gives the following approximate figures:
| Metric | Value |
|---|---|
| Size of most tables | up to a few GB |
| A few large tables | 30 GB and above |
| Full rebuild of smaller tables | a few minutes at most |
| Full rebuild of larger tables | about 30–60 minutes |
| Dedicated server for Manticore | not used by Kiva |
The last point is especially notable.
Kiva does not provision dedicated servers for Manticore. The search engine runs either on an application server or on a server hosting a database replica.
"We never run Manticore on a separate server. It uses very few resources when idle and is very CPU-efficient, so at our scale the additional infrastructure cost is almost zero."
For Kiva, this means that adding a separate search layer did not turn into another cluster that has to be paid for and maintained.
Less load on MySQL, more resources for the application
The main benefit for Kiva is not just faster full-text search.
Moving the search workload out of MySQL freed up resources on the database servers. Those resources can be used for more important application data and operations, while the same infrastructure can now serve more customers.
Manticore also gave Kiva capabilities it did not have before, including more advanced search methods and support for more languages.
Next step: hybrid search
Kiva is also considering Manticore for new applications with AI features.
According to Arda, the team is considering hybrid search , which combines full-text and vector search. For Kiva, this is a natural extension of the existing architecture: Manticore already serves as the search layer for customer data, so new search methods can be added there without moving the source data out of MySQL.
For now, this is only a plan, not something already running in production. But it shows how the search layer can evolve from full-text search toward search that considers both the words in a query and their meaning.
Searching data with a changing structure
At Kiva, Manticore fits into the existing infrastructure and does not require a separate search cluster.
Every customer has their own database and a schema that changes as the application is configured. Manticore combines a periodically rebuilt table with changes from the RT table and returns the IDs of matching records. MySQL remains the primary data store.
As a result, Kiva has moved the full-text search workload off its primary database, made more efficient use of its existing servers, and turned search into a shared platform capability — even when it is impossible to know in advance what fields and entities the next customer will create.