Couchbase · Use case
Product catalog database: fast product pages, filters and Arabic search, with Couchbase
A product catalog database holds what a shopper sees: names and descriptions in Arabic and English, attributes that differ by category, prices, stock and images. It is read far more often than it is written, it must answer search and filters as well as single lookups, and it must hold up when a sale starts. This guide explains why catalogs strain a traditional design, how a document database such as Couchbase serves one, and where it is not the right choice. Interkey, a Couchbase technology partner, designs, builds and supports catalog platforms from Riyadh.
Published 8 min read
In short, for executives
- The problem: product pages, search and filters slow down at peak, and adding a new category or attribute needs a database change.
- The usual answer: keep the master data where it is (ERP or product information system) and serve the storefront from a fast catalog database built for reads.
- The Couchbase approach: each product is one JSON document, read by key from memory, queried with SQL++ and searched with facets, in Arabic and English, in one platform.
- In the Kingdom: Couchbase Server in your own data centre, or Couchbase Capella in a published region in Saudi Arabia.
- What Interkey does: catalog review, data model, sizing, build, data feed from your master system and support from Riyadh.
At a glance
| Question | Answer |
|---|---|
| What it holds | One JSON document per product or variant: names, descriptions, attributes, price, stock and image links |
| Who writes to it | Your master system (ERP or product information system), through a feed; the storefront mostly reads |
| How it is read | By key for a product page; with SQL++ for lists; with the Search service for text search and filters |
| Languages | Arabic and English fields in the same document, with an Arabic analyzer for search |
| Where it runs | Couchbase Server on your infrastructure, or Couchbase Capella, the managed service |
| From Interkey | Catalog review, data model, sizing, build, feed design and support from Riyadh |
Why a product catalog is harder than it looks
A catalog looks like a simple list of products. In production it carries several jobs at once, and each one pulls the design in a different direction:
Read more
- Different attributes per category. A phone has storage and colour, an abaya has size and fabric, a fridge has capacity and energy rating. A fixed table either grows a column for every attribute or hides them in a side table that every page must join.
- Read-heavy, with sharp peaks. Most traffic is browsing. Ramadan, Eid and seasonal sales multiply it within minutes, and the product page cannot be the part that waits.
- Search and filters, not only lookups. Shoppers type a word, then narrow by brand, price band or size, and expect a count beside each filter.
- Two languages. Saudi shoppers search in Arabic and English, sometimes mixing both, with spelling that varies.
- Small, frequent changes. Prices and stock change all day while descriptions rarely do.
Why a product catalog database is often NoSQL
A document database stores each product as one self-describing record, usually JSON. Category-specific attributes sit inside the document, so a new category adds new fields, not a schema migration, and the product page reads one document instead of joining many tables. That is why catalogs are one of the most common reasons teams look at a NoSQL model.
Read more
The trade-off is honest to state: the document is shaped for how the storefront reads, not for every report the business runs. Product data still has an owner, normally the ERP or a product information system, and the catalog database is a fast copy built from it. Our NoSQL database page sets out the four NoSQL types and when an enterprise should choose one.
What each catalog need asks of the database
This is the checklist we start a catalog review with. Each row names the need, what to test before choosing, and the Couchbase feature that answers it.
| Catalog need | What to test | In Couchbase |
|---|---|---|
| Product page in one read | Latency at peak, on your own data | Read by key, served from memory when the item is in the working set |
| New category or attribute | Whether adding a field needs downtime or a migration | JSON documents; fields can differ between products |
| Lists and category pages | Sorting and paging on large categories | SQL++ queries with secondary indexes |
| Text search with filters | Counts per filter, typo handling, relevance | Search service with term, numeric range and date range facets |
| Arabic search | Results for Arabic words with and without prefixes | Search with the Arabic (ar) analyzer |
| Price and stock updates | Update rate without rewriting whole documents | Sub-Document API changes one field |
| Reacting to changes | How other systems learn of a change | Eventing Functions run when a document changes |
| Similar products | Whether recommendations need a second system | Vector search indexes alongside the same documents |
A product catalog database on Couchbase: how the pieces fit
In Couchbase, each product or variant is a JSON document under a key such as product::SKU-10442. The Data service returns it by that key, from memory when it is in the working set; Couchbase describes its data operations as sub-millisecond, which is the vendor's figure, so we measure on your data. Category pages and lists come from SQL++ with secondary indexes.
Read more
Prices and stock change often, so the feed uses the Sub-Document API to update one field without sending the whole product back. When a document changes, an Eventing Function can react, for example to mark a product for review when its price falls below a set floor. Recommendations such as "similar items" can use vector search indexes over the same documents, as our vector database guide explains.
Each service (Data, Query, Index, Search, Eventing) can run on nodes of its own, so heavy search traffic in a sale is scaled on search nodes without resizing the whole cluster.
Relatedvector database guide
Search and filters in Arabic and English
The Search service builds a full-text index over the catalog documents. A shopper's query returns ranked products, and facets return the counts beside each filter: a term facet for brand or colour, a numeric range facet for price bands, a date range facet for new arrivals.
For Arabic, Couchbase ships an ar analyzer designed for Arabic language searches, and each field can be indexed with the analyzer for its language. In practice we index the Arabic and English names and descriptions separately and test with the words your shoppers really type, including common spelling variants and product names written in Latin letters. Search quality is tuned and tested on your catalog, not assumed.
Where Couchbase fits a product catalog, and where it does not
It fits when the catalog is large or varied, read heavily, searched in two languages and must stay fast through sales; and when the team wants product reads, lists, search and filters on one platform instead of a database, a cache and a search engine kept in step.
It does not fit as the master record for product data: the ERP or product information system stays the owner, with its approvals and history. A catalog of a few hundred items with steady traffic is usually served well by the database you already run. And a distributed cluster needs someone to operate it, in-house or contracted.
Running a product catalog database in Saudi Arabia
Catalog data is rarely personal data, but what sits next to it is: carts, sessions and customer profiles. Decide where the whole storefront runs, not the catalog alone; our pages on session stores and customer 360 cover that data. Self-managed Couchbase Server runs on servers, virtual machines or Kubernetes in your own data centre in the Kingdom. As of November 2026, Couchbase Capella's published regions include Google Cloud's Dammam region (me-central2); our Capella or self-managed comparison sets out regions and billing.
Interkey's engineers work from Riyadh, in Arabic and English, and support the platform after go-live: data model, indexes, search tuning, backup, upgrades and your team's questions. Our Couchbase page covers the wider services.
Relatedsession storescustomer 360Capella or self-managed comparison
How Interkey delivers a product catalog database
-
Catalog review.
Categories, attributes, languages, update rate, peak traffic, the search and filter journeys, and where the data must stay.
-
Data model and feed.
Document shape, keys, indexes and the feed from your ERP or product information system, including how deletions and price changes arrive.
-
Sizing and model.
Couchbase Server or Capella, nodes per service, memory and replicas, quoted with our work.
-
Build and search tuning.
The cluster, security, backup and monitoring, then Arabic and English search tested with real queries.
-
Load test and cut-over.
A load test shaped like your busiest sale, then traffic moved page type by page type, with the old path kept as a fallback.
-
Support and handover.
Support from Riyadh after go-live, and training for your team.
Questions buyers ask
What is a product catalog database, and does it replace our ERP or PIM?
It is the database the storefront reads: product pages, lists, search and filters. It does not replace the ERP or product information system, which stays the owner of product data with its approvals and history. A feed copies approved changes into the catalog database, shaped for fast reads.
Why do retailers choose a NoSQL database for the product catalog?
Because products in different categories have different attributes. In a document database each product is one JSON document, so a new attribute is a new field rather than a schema change, and a product page is one read instead of many joins. Reports across the business still belong on the systems built for them.
Can Couchbase search our product catalog in Arabic and English?
Yes. The Search service indexes Arabic and English fields, Couchbase provides an analyzer designed for Arabic, and facets return the counts beside each filter. Results depend on how fields are indexed and on real shopper queries, so we test with the words your customers type before go-live.
Can the catalog and the rest of our storefront data stay in Saudi Arabia?
Yes. Self-managed Couchbase Server runs on infrastructure you operate in the Kingdom, and as of November 2026 Couchbase Capella's published regions include Google Cloud's Dammam region. Carts, sessions and profiles usually hold personal data, so check where backups, monitoring data and support access go as well.
How is a Couchbase product catalog priced in KSA?
Self-managed Couchbase Server Enterprise is a subscription priced by production nodes and quoted on request; Capella is billed per node per hour. Node count follows from catalog size, the share kept in memory, replicas and how heavy search is at peak. We size first, then quote, with our own work on separate lines.
How long does it take to move a product catalog to Couchbase?
It depends on the number of categories and languages, how clean the master data is, how the feed is built, the search journeys in scope and your security review. Moving page types one at a time keeps the risk small. We give an estimate after the catalog review, not before.
Next
Read next
Next step
Review your product catalog design with Interkey
Tell us roughly how many products and categories you carry, which languages shoppers search in, where product data comes from today and whether the platform must stay in the Kingdom. We will reply with a first design and what a sizing would cover.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia