Medusa Search vs Algolia
This guide compares Medusa Search and Algolia to help you decide which one to use for your Medusa project.
What is Medusa Search?#
Medusa Search is a managed search service for Cloud projects. It stores your search indexes outside of your database and serves search queries for them, from full-text queries with relevance ranking to vector search over embeddings.
What is Algolia?#
Algolia is a hosted search service that provides full-text search, typo tolerance, and relevance tuning out of the box. It requires you to create an account, provision an index, and manage the search keys and configuration for each environment.
Comparison Summary#
Concern | Medusa Search | Algolia |
|---|---|---|
Medusa provisions the service and passes the credentials to your application. | Create an account, provision an index, generate keys, and add them to every environment. | |
The PostgreSQL provider indexes into your local database, so no service to run. | No local engine. Local development points at a real Algolia index. | |
None by default. Medusa provides Medusa Search and manages the infrastructure for you out of the box. | A Search Module Provider you build and maintain to connect your application to Algolia and manage the search indexes. | |
Medusa manages one set of indexes per environment for you. | You name and provision an index per environment. | |
No separate subscription. Your plan includes a monthly allowance of search requests, and anything above it is Flex Usage. | A separate subscription, priced on the records you store and the search requests you make. | |
Medusa provides the indexing logic and keeps the indexes current automatically. | You must implement and maintain the indexing logic in your Algolia Search Module Provider to work with the Search Module. | |
Both supported, and you opt into each one per query. | Supported and configurable per index. | |
Any number of fields, but not alongside a vector query. | Needs a replica index per sort order. | |
Supported by Medusa's InstantSearch adapter. | Supported by Medusa's InstantSearch adapter. | |
Uses your indexes automatically. | Uses your indexes automatically. |
Setup and Infrastructure#
Medusa Search#
Medusa provisions Medusa Search for every Cloud environment. It passes the credentials to your Medusa application, which registers the provider for you. So, you don't need to manually configure or maintain the search infrastructure. You can immediately start searching.
Algolia#
Algolia takes considerably more work before you can run a single search. Algolia has no self-hosted option, so it operates the servers, but you configure and maintain everything around them:
- Create an Algolia account and application.
- Provision an index for every environment, and pick a naming scheme that keeps them apart.
- Generate an admin key for writes and a search-only key for reads, then store both as environment variables in every Cloud environment.
- Configure the index settings, including searchable attributes, faceting, ranking rules, and typo tolerance.
- Repeat steps 2 to 4 for every environment you add, and keep the settings identical across all of them.
Step 4 is the one that keeps costing you. Index settings are dashboard configuration in Algolia by default, so they live outside your codebase and drift out of version control unless you push them through the API as part of a deployment.
Only after all of that do you connect Algolia to Medusa, which requires creating a Search Module Provider as explained in the Integration with Medusa section.
Local Development#
Medusa Search runs on Cloud only. In local development, Medusa registers the PostgreSQL Search Module Provider instead, which indexes into your local database. You declare and test an index without running a search engine on your machine. You can also connect to your environment's search endpoint.
Algolia has no local engine, so local development points at a real Algolia index, usually a separate development one. Every developer either shares that index or gets their own, and both choices cost you records.
Integration with Medusa#
This is the largest difference between the two, since it decides how much search code you own.
With Medusa Search#
Medusa provides Medusa Search out of the box. You don't need to spend time building, maintaining, or configuring it yourself. The infrastructure is ready for you to use immediately, allowing you to focus on defining your search indexes and integrating them into your application.
With Algolia#
Medusa doesn't maintain a Search Module Provider for Algolia, so you have to build a custom one. A Search Module Provider implements the interface the Search Module calls to interact with the search engine.
The provider needs to handle several responsibilities:
- Provide the connection layer to create, migrate, and delete a physical index from an index definition, including translating each field type and modifier into Algolia's index settings.
- Upsert and delete documents in batches, and delete by a filter.
- Compile the Search Module's filter tree, including
$or,$not, and several operators on one field, into Algolia's filter syntax. - Compile facets, sorting, pagination, and search options into Algolia queries, and decide what to reject when Algolia can't serve a request.
- Map Algolia's response back into the shape the module expects, including the relevance score and the facet results.
So, by integrating Algolia, you spend more time building and maintaining the search infrastructure yourself, compared to using Medusa Search, which is ready to use out of the box.
Refer to Search Module Providers for how the module loads and calls a provider, and to Create Search Module Provider for the interface to implement.
Environments and Previews#
Medusa Search#
Medusa gives each Cloud environment its own set of Medusa Search indexes, scoped by the environment's handle, so a preview environment never writes to production indexes. When you configure a base environment in the shared previews settings, Cloud copies the base environment's indexes into the new preview environment along with its database.
Algolia#
With Algolia, index isolation is your responsibility. The usual approach is an index name prefix per environment, set through an environment variable, plus a decision about what a preview environment searches.
A preview that points at the production index is a write risk, and a preview with an empty index needs a full sync before search works. Each environment's records also count toward your record allowance, so preview environments have a price.
Cost and Packaging#
The two options bill for different things, which makes a direct price comparison misleading. Compare the shape of the cost instead:
Option | What you pay for | What drives the cost up |
|---|---|---|
Medusa Search | No separate subscription, since Medusa Search is available on all Cloud plans. Each plan includes a monthly allowance of search requests. Refer to Plans & Pricing for the allowance your plan includes. | Search requests beyond your plan's allowance, which count as Flex Usage. |
Algolia | A separate subscription, priced on the records you store and the search requests you make. | Catalog size, replica indexes, non-production indexes, traffic, and the plan tier that a feature requires. |
Algolia also has some important considerations to keep in mind:
- Sorting. Each sort order needs its own replica index in Algolia, and a standard replica holds its own copy of the records. Several sort orders on a large catalog multiply the records that Algolia bills you for.
- Record count, not product count. If you flatten variants or localized fields into separate records in Algolia, your record count grows much faster than your catalog does.
Other Cloud Usage Algolia Affects#
Using Algolia for Search on Cloud can drive up the costs of the following Cloud usage metrics:
- Data Transfer covers external service communications, so every index write and every search your backend sends to Algolia counts toward it, along with the responses. A storefront that searches through your API routes puts every query on this metric.
- Compute covers the indexing work, since the seed and the event handlers that write to Algolia run in your Medusa application.
Refer to Usage on how to monitor both metrics.
Indexing and Synchronization#
The Search Module orchestrates the flow for indexing and data synchronization. It uses the methods implemented in the configured provider to interact with the underlying search engine, whether it's Medusa Search or Algolia.
Medusa maintains Medusa Search, so it already implements all the necessary methods for indexing and synchronization.
For Algolia, it's your responsibility to provide an implementation that translates the Search Module's calls into Algolia API requests, allowing the Search Module to manage indexes and push documents into Algolia. You must maintain this implementation as Medusa updates the Search Module and its indexing logic.
Search Capabilities#
The Search Module provides the interface to perform search queries, but each Search Module Provider must translates those features into the specific capabilities and syntax of the underlying search engine.
Capability | Medusa Search | Algolia |
|---|---|---|
Full-text relevance | Relevance scales with the weight you set on each field. | Configurable ranking rules and custom ranking on top of the default tie-breaking. |
Typo tolerance | Supported and configurable per index and query, with word-length thresholds and field exemptions. | Supported and configurable per index and per attribute. |
Filters | Every operator the Search Module offers, including | A filter syntax with numeric, tag, and facet filters, on attributes you mark as facetable. |
Synonyms | Not supported. An index that declares them fails at startup. | Supported, with one-way, alternative-form, and placeholder synonyms. |
Facets | Value and range facets. The hits, the count, and every facet of a query run as one search request. | Facet counts and facet value search on faceted attributes. |
Highlighting and snippets | Supported on searchable fields, with your own markers and optional snippets. | Supported, and the front-end libraries render it for you. |
Sorting by an attribute | Any number of fields, but not alongside a vector query. | Needs a replica index per sort order. A standard replica holds its own copy of the records. |
Merchandising and rules | Not supported. Order results with your own logic in an API route. | Supported, with rules that pin, boost, or filter results for a given query. |
Vector and semantic search | Hybrid search that blends text and vector results by a semantic ratio, on the Scale and Enterprise plans. You compute the embeddings, or Medusa Search creates them for you on the Enterprise plan. | Available through Algolia's AI search features, on higher plans. |
Geo search | Not supported. An index that declares a geo field fails at startup. | Supported, with radius and bounding-box queries. |
Deep pagination | Up to the 10,000th result. | A configurable pagination limit caps it, and the plan bounds that limit. |
Analytics and A/B testing | Analytics dashboard to track search volumes, queries with no results, and more. | Built in, including click and conversion analytics and index A/B tests. |
Storefront Integration#
InstantSearch is a family of open source UI libraries, which render a search interface from widgets such as a search box, a hit list, facet filters, and pagination. It's available for plain JavaScript, React, Vue, and Angular.
Medusa's InstantSearch adapter connects those widgets to Medusa's Search Module. It works with any Search Module Provider you integrate in your Medusa application, including both Medusa Search and your custom Algolia provider.
1import {2 createInstantSearchAdapter,3} from "@medusajs/instantsearch-adapter"4import { sdk } from "./sdk"5import {6 Configure,7 InstantSearch,8} from "react-instantsearch"9 10const PRODUCT_INDEX_NAME = "product"11 12export const { searchClient } = createInstantSearchAdapter({13 sdk,14 path: "/store/search",15})16 17const Search = () => (18 <InstantSearch19 indexName={PRODUCT_INDEX_NAME}20 searchClient={searchClient}21 >22 <Configure hitsPerPage={12} />23 {/* Render search widgets */}24 </InstantSearch>25)
Refer to the InstantSearch Adapter guide for more details and examples of setting up search and filters.
Admin Dashboard Search#
The Medusa Admin dashboard's global search calls the Admin Search API route, which uses the Search Module for every entity that has an index and falls back to database queries for the rest. Declaring an index for an entity therefore improves admin search with no extra work.
This is agnostic across different Search Module Providers, so it works the same for Medusa Search or your custom Algolia provider.
Comparisons to Other Search Engines#
The following guides compare Medusa Search to other search engines: