Is it worth investing resources in a third-party search engine? Here are our reasons.
We are continuously working on improving our product Feedback by Hexmos day by day for the upcoming release.
New features and pages are coming up, the UI is changing, bugs are being noticed and fixed, and many changes are happening in the product. As the product grows, we realize we need to improve the navigation across the product.
We already have a sidebar and a client-side search package cmdk to navigate to different screens, but difficulties arise when we want to search for different user profiles, teams, team performance, etc., which forces us to integrate a better third party search engine for Feedback.
Another reason for a dedicated search engine is that we have other products in the chain such as FeedZap, which requires a complex text search operations in future.
Considering this, we are planning to put effort into implementing a dedicated, powerful search engine that adapts to our use cases and resource availability.
How to Choose the Right Search Engine that fit your Needs
There are a lot of search engines available, including open-source search engines, serverless, server-based, etc.
Before diving in to figure out the right one, it's always better to do an analysis of your requirements and infrastructure, including present and future needs.
For some products, searchable data are minimal but require a decent search feature with minimal operation, yet can't afford a dedicated server.
For other products, the dataset is larger, requires additional complex search operations and have enough resources to load a dedicated search engine.
Based on this, I reviewed a few popular search engines.
Need Decent Performance, Dataset Is Small, and Can't Afford a Server
PostgreSQL Full-Text Search
If you are using PostgreSQL and don't want to maintain any other index-based database, then PostgreSQL Full-Text Search (PSFTS) is a good option. However, it is not recommended for large use cases where you deal with millions of transactions and extensive data management.
Bleve
Bleve is another option to consider if your project is within the Go ecosystem. It is recommended if you can't rely on powerful server-based search engine services. Here is the benchmark report on Bleve.
Tantivy
Tantivy is written in Rust and is particularly useful for Rust-based projects. It has received numerous positive feedbacks and is a good option to consider.
Need Powerful Performance, Large Dataset, and Can Afford a Server
Need Powerful Performance, Large Dataset, and Can Afford a Server
If you own a server or cloud instance and require a powerful, scalable search engine with full control, then a server-based option is the way to go.
Our considerations and requirements led us to choose a server-based search engine. We have enough resources to host it, and it is better than serverless options for
- Long-term use
- Scalability
- Additional support for complex search operations such as:
- Facet search: it means when shopping online, you might search for "laptops" and then use facet search to narrow down results by selecting filters like "price under $1000," "brand: Apple," and "RAM: 16GB."
- Multisearch: Consider travel website which might let users search for flights, hotels, and car rentals all at once and display back the integrated results.
- Search-as-you-type: It provides real-time search results based on each key stroke.
- Common search system for mulitiple products.
After extensive filtering, we narrowed it down to four options in this category such as:
Here is a comparison between them:
| Criteria | meiliSearch | Typesense | Pisa Search | Manticore |
|---|---|---|---|---|
| Search-as-you-type | yes | yes | No | No |
| facet search | yes | yes | No | No |
| multiple schema/product support | yes | yes | - | yes |
| RAM usage | for 224 MB disk:~305 MB RAM prmary index location is disk | primary index location is RAM, for 100MB disk requires 300MB RAM | - | - |
| CPU Usage | for 12 core machine it uses maximum 6 core github issues related to high cpu usage | for 4vCPU handle 104 concurrent search/seconds | - | - |
| typo, synonyms handling | yes | yes | - | - |
We filtered out PISA Search and Manticore because neither of them offers search-as-you-type and facet search features, which are required for our application.
Continue reading the full article here: https://journal.hexmos.com/we-chose-meilisearch-over-10-other-search-engines-despite-a-major-drawback/
Top comments (0)