Algolia alternative for small catalogues: Algolia vs Elasticsearch, OpenSearch and managed search

For a few thousand items, picking the search engine is the easy part. A fair comparison of Algolia, Elasticsearch, OpenSearch and Tomorrow Central Search, and when each one is the right choice.

Which Algolia alternative fits a small catalogue?

Most teams looking for an Algolia alternative are not unhappy with Algolia's search. They are unsure they need a full search platform for 3,000 products, or they have looked at Elasticsearch, seen "free and open source", and not yet counted who will run it.

The short answer for a catalogue of a few hundred to a few tens of thousands of items:

• Choose Algolia if you have developers, want a hosted search API, and expect to need synonyms, personalisation, a large rules budget or a merchandising team's tools.
• Choose Elasticsearch or OpenSearch if you have engineers who want full control, need complex queries or aggregations, must run on your own servers, or already operate one of them.
• Choose a managed catalogue search such as Tomorrow Central Search if nobody on the team will own search, your catalogue is public and within its plan limit, and what you need is typo-tolerant results, a few pinned products and a report of searches that found nothing.

All three can work at this size. The difference is how much work each one leaves with you, and which features you will actually use.

At a few thousand items, the index fits anywhere. The real choice is who carries the work around it: importing the catalogue, tuning results, reading the reports and keeping it running.

This comparison is for store owners, catalogue businesses and small development teams. If you are still working out why your current search fails, start with the pillar guide on site search for a catalogue. Competitor details below come only from each vendor's own documentation and pricing pages, read on 19 October 2026. Check them again before you buy: plans change.

What does search for a small catalogue actually need?

Before comparing products, write down what your search has to do. For most small catalogues the list is short:

1. Find items despite misspellings. Visitors type "crochet hok" and "pastl". Typo tolerance means the search still returns the intended item when a word has a missing, extra, swapped or wrong letter.
2. Handle the words visitors use, not only yours. A visitor types "trousers" and you list "pants". A synonym rule tells the search that two words mean the same thing.
3. Put a key product first for a key search. Usually called rules or merchandising: pin an item to the top, hide one you don't want shown.
4. Tell you what failed. A list of zero-result searches (queries that returned nothing) and what people clicked.
5. Stay within a predictable cost. Know what happens when traffic spikes.
6. Not need a person to keep it alive. Upgrades, backups, monitoring and resizing are someone's job if you run the engine yourself.

Most small catalogues need items 1, 3, 4 and 6 from day one. Synonyms matter more as the catalogue's language drifts from your customers'. Personalisation, AI ranking and visual merchandising tools matter when you have the traffic to learn from and the people to manage them.

What are your options?

A hosted search API: Algolia

Algolia describes itself as "a hosted AI search and retrieval platform", built API-first. You send your catalogue to it as JSON records, query it through its API, and build the search box in your own front end. Algolia runs the servers. You pay by search requests (each query sent to it) and records (each item stored), with a free plan to start on.

A search engine you run, or rent as a cluster: Elasticsearch and OpenSearch

Elasticsearch (from Elastic) and OpenSearch (an Apache 2.0 open-source project) are general-purpose search engines. You can run either on your own servers, or rent it as a managed cluster: Elastic Cloud from Elastic, or Amazon OpenSearch Service from AWS. Either way, your team designs the index, writes the queries, and builds the search box and the reporting. They are powerful, and they handle catalogues far larger than yours. They also hand you every decision.

A managed catalogue search: Tomorrow Central Search

A managed catalogue search runs the engine, the import and the reporting for you. You bring the catalogue as a file or an import of your website, and put a search box or results page on your site. Tomorrow Central Search is one example, with a free plan, and is also available on-prem. It is narrower than the other two by design: built for public catalogues that fit within the free plan's limits (5,000 products at the time of writing; see the Search page). For larger catalogues, scale up from there with ITMTB.

Algolia, Elasticsearch, OpenSearch and Tomorrow Central Search side by side

Competitor details are from each vendor's own pages, accessed 19 October 2026; the sources are listed at the end. Prices are quoted only where the vendor's page states them.

Two things stand out at small scale. Algolia's free plan holds more records than Tomorrow Central's (50K against 5,000 products), and both include about 10,000 searches a month, so if you have a developer and need more items, Algolia's free plan is a strong option. Elasticsearch and OpenSearch have no per-search price at all when you run them yourself, but the bill moves to servers and people.

How much work does each option leave you?

Feature tables hide the ongoing work. This is where small teams get caught.

The common failure is not choosing the wrong engine. It is choosing an option whose ongoing jobs nobody on the team owns. A self-run cluster with no owner drifts out of date. An API integration with no owner stops syncing when the store's export changes. A zero-result report with no owner is never read.

When to choose each one

Choose Algolia when

• You have at least one developer who will own the integration and the search front end.
• You need synonyms now, or AI features such as AI Ranking, AI Synonyms or personalisation (listed on Grow Plus; Elevate adds NeuralSearch and real-time personalisation).
• You expect to need many merchandising rules, or a merchandising team will use visual tools such as Merchandising Studio (Elevate).
• Your catalogue is large or growing fast, or you want longer analytics retention.
• You want agents to query your index through a vendor-run MCP server today.

Choose Elasticsearch or OpenSearch when

• You have engineers who want full control of indexing, ranking and queries, and the time to own a cluster.
• You need complex queries, aggregations or facets across many fields, or to combine catalogue search with other data.
• Search must run entirely on your own servers, or you already run Elasticsearch or OpenSearch for logs or other work.
• Your data is large enough that a per-request price would cost more than servers and staff.

Choose a managed catalogue search when

• Nobody on the team will own search as an engineering system.
• The catalogue is public and sits within the plan's item limit.
• What you need is typo-tolerant results, a few pinned or hidden items for key searches, and a report of failed searches.
• You want to start free, and you would rather searches pause at a limit than run up a bill.
• You need it on your own servers but don't want to build it: Tomorrow Central Search is also available on-prem through ITMTB.

Keep your platform's built-in search when

• The catalogue is small, searches are few, and testing it with your customers' real misspellings still finds the right items.

Elasticsearch or Algolia for a small store?

The usual comparison, Elasticsearch vs Algolia, is framed around scale and cost per search. At a few thousand items those matter less than three other things.

Defaults. Algolia tolerates typos without configuration. In Elasticsearch and OpenSearch, typo handling is something you add to the query and tune (OpenSearch's docs say fuzziness is disabled in match queries unless you specify it). Neither is wrong; one is a product decision made for you, the other is yours to make.

Pricing shape. Algolia charges for usage above a plan's inclusions: requests and records. Running Elasticsearch or OpenSearch yourself has no per-search price, but a cluster costs money every hour whether anyone searches or not, and someone has to run it. Rented clusters sit in between: Amazon OpenSearch Service bills instance hours and storage, or compute units on its serverless option.

Who finishes the job. Algolia gives you analytics and rules out of the box. With Elasticsearch or OpenSearch, the engine is the starting point: query logging, a zero-result report, a pinning workflow and the search box are all yours to build. For a team of one, that is the deciding factor more often than price.

What Tomorrow Central Search does, and what it doesn't

Tomorrow Central Search is aimed at the third case: a public catalogue, no search engineer, and a need for search that works this week.

1. You don't have a developer for an integration. Upload a CSV, JSON or Google Merchant feed, or import your verified website, including Shopify and WooCommerce stores. Rows that can't be used come back with the reason. Then paste the ready-made search box, link to a hosted results page, or show results on your own page.
2. Visitors misspell product names. Corrections come from the words in your own catalogue, so a fix always points at something you actually list.
3. A key search must show a key product. Pin up to three items to the top and hide ones you don't want shown for any search, and preview results with and without your rules before they go live.
4. You don't know what visitors fail to find. Statistics show top searches, zero-result searches and their rate, clicks, corrections and speed. Your own test searches aren't counted.
5. You can't risk a surprise bill. The free plan charges nothing. Past the monthly limit there is a grace of up to 10% more within seven days, then searches pause until the next month.
6. Someone else must not use your search. Your search key works only on your verified website, so another site can't embed your catalogue, and your monthly searches are protected from use elsewhere.
7. Search has to stay inside your environment. Besides the self-serve SaaS, Search is available on-prem through ITMTB.

Where it stops, so you can rule it out quickly:

• It does not let you edit synonyms yourself today. If synonyms matter now, Algolia or Elasticsearch handles them.
• It is full-text search with catalogue-sourced correction, not semantic or "chat with your catalogue" search.
• The free plan holds up to 5,000 products at the time of writing. For larger catalogues, scale up with ITMTB, or choose Algolia, Elasticsearch or OpenSearch.
• It is for public catalogues on a website you can verify, not internal documents.
• The free plan's limits are defaults that can change; the Search page shows current figures.

The setup itself, step by step, is in how to add search to a website. Why a catalogue of this size fits comfortably in a relational full-text index is covered in building enterprise search on MySQL FULLTEXT.

Example: a craft supplies store with 1,800 items

Example scenario, not a customer case study. A craft supplies shop lists about 1,800 items: yarns, threads, paints and kits. Its store's built-in search matches exact words only, so "embroidry floss" and "acrylc paint" return nothing. The team is the owner, one part-time assistant, and a freelance developer who helps a few days a month.

• Elasticsearch or OpenSearch: the freelancer could build it, but the shop would pay for a cluster that nobody looks after between visits. Ruled out on ownership, not capability.
• Algolia: the free plan covers the catalogue and the traffic. The freelancer would build the sync and the search box. It fits if the freelancer's time is budgeted for changes, and it becomes the clear choice if the shop later wants synonyms, such as "floss" for "stranded cotton".
• Managed catalogue search: the owner uploads the store's product export, pastes the search box, pins the season's starter kit for "beginner", and the assistant reads the zero-result list each Monday. Nothing to maintain between the freelancer's visits.

The shop picks the managed option for now, and writes down the trigger to revisit: "When we need synonyms or pass the free plan's item limit, re-run the comparison." That trigger is the useful part. A choice made for a small catalogue should name the point at which it stops fitting.

Common mistakes when picking site search

1. Counting the licence and not the people. Free software on a server still needs an owner.
2. Buying for features you won't use. Personalisation and AI ranking need traffic and someone to manage them.
3. Ignoring the rules limit on the plan you'll actually be on. Algolia's Grow plan lists 10 rules per index.
4. Not testing with real misspellings. Take 20 to 30 queries from your current search log and try them on each option.
5. Forgetting what happens at the limit. Know whether a busy month bills more, slows down or pauses.
6. Choosing without an exit point. Write down the catalogue size or feature need that would make you switch.
7. Uploading private data to a public search. Prices for one customer or internal stock notes don't belong in a public index.

A quick checklist to decide

Answer each question yes or no.

1. Will someone on the team own search as an engineering system for the next year?
2. Do you need synonyms in the first month?
3. Do you need personalisation, AI ranking or more than ten merchandising rules?
4. Must search run on your own servers?
5. Do you already run Elasticsearch or OpenSearch for something else?
6. Is your catalogue public and within the free plan's limits (5,000 products at the time of writing; see the Search page)?
7. Would you rather searches pause at a limit than create a bill?
8. Do you need a zero-result report without building one?

• Yes to 1 and 4 or 5: Elasticsearch or OpenSearch.
• Yes to 2 or 3, with a developer available: Algolia.
• Yes to 6, 7 and 8, and no to 1: a managed catalogue search. If 4 is also yes, or your catalogue is larger than the free plan, ask ITMTB about on-prem and larger plans.

Key takeaways

• At a few thousand items any of these can serve the index; choose on who will carry the ongoing work.
• Algolia is the strongest choice for teams with developers who need synonyms, personalisation, many rules or merchandising tools, and its free plan covers 50K records.
• Elasticsearch and OpenSearch suit engineers who want full control, complex queries or on-prem, and accept running a cluster and building the reporting.
• A managed catalogue search suits teams with no search owner and a public catalogue within its plan limit: typo tolerance, pinning and a zero-result report without an integration.
• Compare pricing by shape, not headline: per request and record, per server hour, or a fixed monthly limit that pauses.
• Write down the point at which your choice stops fitting, and revisit it then.

Try it on your own catalogue

The Search free plan covers up to 5,000 products, 10,000 searches a month and one search project at the time of writing. Sign up with Search switched on, upload your catalogue or import your verified website, and run the same 20 misspellings you used to test the others. Current limits are on the Search page. If you need it inside your own environment, ask ITMTB about on-prem enterprise search.

References

All accessed 19 October 2026.

• Algolia pricing: plans, included requests and records, overage prices, rules per index, analytics retention, Merchandising Studio.
• What is Algolia?, Algolia docs.
• Typo tolerance, Algolia docs.
• Adding synonyms, Algolia docs.
• Model Context Protocol, Algolia docs.
• Elastic pricing: Serverless, Cloud Hosted and self-managed pricing models.
• Self-managed Elasticsearch cluster, Elastic docs.
• Fuzzy query, Elasticsearch docs.
• Search with synonyms, Elastic docs.
• Searching with query rules, Elasticsearch docs.
• Elasticsearch deprecations: Behavioral Analytics CRUD APIs deprecated in 9.0.0.
• Agent Builder MCP server, Elastic docs.
• Fuzziness, OpenSearch docs.
• Synonym token filter, OpenSearch docs.
• User Behavior Insights, OpenSearch docs.
• Querqy, OpenSearch docs.
• Install and configure OpenSearch, OpenSearch docs.
• OpenSearch MCP Server, OpenSearch docs.
• OpenSearch FAQ: licence.
• Amazon OpenSearch Service pricing, AWS.
• Building enterprise search on MySQL FULLTEXT, Aakash Ahuja, 2026.