Search Module Providers
In this guide, you'll learn about Search Module Providers in Medusa, including how to register them and choose which one holds each index.
What is a Search Module Provider?#
A Search Module Provider implements the logic of talking to a search engine, including creating indexes, writing documents, and running queries. The Search Module then uses the registered providers to serve every index.
A provider holds the integration logic only. It never decides when a document changes or when an index is filled, as the Search Module drives all of that and calls the provider to carry it out.
The provider is responsible for | The Search Module is responsible for |
|---|---|
Creating and migrating the physical indexes in the search engine. | Reading your index definitions and deciding which indexes exist and when they change. |
Writing and deleting the documents the module hands it. | Filling an index by running the definition's |
Translating a search query into the engine's own query language. | Subscribing to events and routing each one to the definitions that declared it, so indexes stay current. |
Reporting whether a write finished, which lets the module wait on engines that apply writes asynchronously. | Versioning an index, rebuilding it when its definition changes, and running the catch-up pass that follows a full run. |
Available Search Module Providers#
Medusa provides the following Search Module Providers:
Custom Search Module Providers#
You can also create a custom provider to integrate a search engine that Medusa doesn't support out of the box. You only implement the methods that talk to that engine, as shown in the table above. Refer to the Create Search Module Provider guide for the methods to implement.
Register Multiple Providers#
The Search Module supports more than one provider at a time. Each index definition picks one through its provider property, so a high-traffic index can live on a dedicated engine while quieter indexes stay on PostgreSQL.
For example:
1module.exports = defineConfig({2 // ...3 modules: [4 {5 resolve: "@medusajs/medusa/search",6 options: {7 default_provider: "search-postgres",8 providers: [9 {10 resolve: "@medusajs/medusa/search-postgres",11 id: "search-postgres",12 options: {13 language: "english",14 },15 },16 {17 resolve: "./src/modules/my-search-provider",18 id: "my-engine",19 options: {20 // provider options...21 },22 },23 ],24 },25 },26 ],27})
Default Search Module Provider#
An index definition that names no provider uses the module's default provider. The Search Module resolves the default once when it initializes, so a misconfiguration fails at startup rather than on the first query.
Scenario | Default Provider |
|---|---|
One provider is registered. | The registered provider. |
Multiple providers are registered and the module has a | The provider whose identifier matches |
Multiple providers are registered and the module doesn't have a | The module throws at startup because it can't determine a default provider. |
Multiple providers are registered and the module has a | The module throws at startup because it can't determine a default provider. |
Select a Provider by its Identifier#
Every provider declares its own identifier, such as search-postgres for the PostgreSQL provider and search-medusa for the Medusa Search provider. A custom provider declares one too, as a static identifier property on the service it exports:
An index definition then selects a provider by that identifier: