Electronics and DIY are catalogs where the complexity is in scale, not design. Tens of thousands of SKUs, each with dozens of technical attributes such as power, connector, size, compatibility, and protection class, many variants, and rapidly changing stock. The business outcome this kind of store fights for is measured in one number: how many milliseconds it takes a customer to get from search to the right product page. The slower filtered results load, the higher the bounce rate and the lower the conversion. Below is an open analysis of what Saleor provides for this task. This is not a KT.Team case study, but an overview of the platform's capabilities based on official documentation and source code.
Why Saleor fits a large technical catalog
Saleor is an open-source headless commerce platform under the BSD-3-Clause license, with a single GraphQL API (github.com/saleor/saleor). Three built-in capabilities matter for an electronics catalog.
First is a flexible product model. Products are described through types, attributes, and metadata that are defined dynamically. Attributes are created independently of product types, and for each one you can separately control visibility in faceted search and on the product page (docs.saleor.io/developer/attributes/api). That means "voltage," "thread type," or "energy efficiency class" are not hardcoded, but configurable entities that immediately become filtering dimensions.
Second is multichannel. Saleor natively supports multiple sales channels with separate pricing and availability by channel. For a DIY retail chain with different regions and currencies, this removes the need to duplicate the catalog.
Third is an API-only architecture. The backend exposes data only through GraphQL, which matches the approach of "touching the tool's core as little as possible": business logic and the storefront are built alongside it, without forking the platform.
Where Saleor stops and why search should be externalized
Honesty matters here. Filtering in Saleor itself works through the GraphQL `where` mechanism, which replaced the old `filter`: it supports `AND`/`OR`, `eq` and `oneOf`, attribute filtering by slug, and pagination (docs.saleor.io/api-usage/filtering). This is enough for clean catalog queries. But full-text search in Saleor is a separate root `search` argument, and the documentation explicitly recommends moving full faceted search with value counts and sub-second response times on tens of thousands of SKUs to an external engine (Elasticsearch or Algolia) through Saleor Apps. This is the real meaning of "read before you write": do not invent a search index on top of a relational database, use a mature specialized standard.
Saleor Search App: an index that stays up to date on its own
Saleor has an official Search App for integration with Algolia (docs.saleor.io/developer/app-store/apps/search). What it does in practice:
- Indexes products, categories, and pages and lets you search them through the Algolia API. Each product variant becomes a separate record in the index, which is the right level of granularity for electronics with its many variations.
- Creates separate indexes per channel using the `PREFIX.CHANNEL_SLUG.CURRENCY_CODE.products` pattern, so price and availability in results always match the specific channel.
- Preconfigures facets by product type, categories, price ranges, and stock status, so basic storefront filtering works out of the box.
- Synchronizes through webhooks: when a product is created or updated, variant stock changes, or categories and pages are edited, the index updates automatically without manual runs.
This creates a separation of responsibilities: Saleor is the source of truth for products and attributes, and Algolia is the layer for fast search and facets. The storefront, for example on Next.js, queries the search engine for results and filters and Saleor for the detailed product page and checkout. This is a loosely coupled, replaceable architecture: the search layer can be swapped (Algolia → Elasticsearch/Typesense) without rewriting the core.
Pitfalls you can spot in advance
An honest analysis has to name the limitations. Algolia has a record size limit of roughly 10 KB. Electronics products with long descriptions and many attributes can exceed it. Search App addresses this with configurable field filtering: fields not needed for search, such as the full description, heavy metadata, and media URLs, are disabled to stay within the limit. The initial bulk import is started manually and must finish with the panel open, so it is a one-time launch task that should be planned. Finally, splitting the catalog into channel-based indexes means more indexes, which is normal but must be accounted for in search engine pricing.
Business outcome and process flow
The combination of Saleor plus an external search engine aims at one measurable effect: the path from search to product page drops to fractions of a second even on a catalog with tens of thousands of SKUs, because faceted results are served from an index rather than ad hoc relational queries. At the same time, the business gets replaceability, since the search layer can change without replacing the platform, and automatic result freshness through webhook synchronization.
Key takeaways on cataloging and search. Restructure the process around layer separation: (1) the content manager maintains products and attributes only in Saleor as the single source of truth; (2) a webhook automatically sends changes to the search index, with no manual exports; (3) the storefront takes faceted results from the search engine, and the product page and checkout from Saleor. Then "speeding up the path from search to product page" becomes not a one-off optimization but a property of the process itself: every catalog change automatically reaches fast search, and response speed does not degrade as SKU counts grow.
