Couchbase · Key-value store
Key-value database: fast lookups by key for sessions, profiles and carts, with Couchbase
A key-value database stores each record as a value under a unique key and returns it by that key, which makes it the usual home for sessions, user profiles, shopping carts and preferences. Couchbase is a distributed key-value store that keeps the data your application reads most in memory, writes it to disk and keeps replicas on other nodes, and it can also query the same JSON with SQL++. Interkey, a Couchbase technology partner, designs, builds and supports Couchbase key-value workloads from Riyadh.
In short, for executives
- What it is: a database that saves each record under a unique key and returns it by that key, quickly and at high volume.
- What it is used for: login sessions, customer profiles, shopping carts, preferences and other data the application already knows how to find.
- The Couchbase approach: memory first, with the working set served from RAM, writes persisted to disk and replicas on other nodes. Couchbase describes its data operations as sub-millisecond, which is Couchbase's own figure; measure it on your own workload.
- In the Kingdom: self-managed Couchbase Server in your own data centre, or Couchbase Capella in a published region in Saudi Arabia.
- What Interkey does: the workload review, key and data design, sizing, build, migration and support from Riyadh.
At a glance
| Question | Answer |
|---|---|
| What it stores | Items, each a key and a value; the value is JSON or binary |
| How data is read | By key, from memory when the item is in the working set; JSON values can also be queried with SQL++ |
| How it scales | A cluster of nodes; data spreads across them, and nodes can be added as load grows |
| How data survives a failure | Persistence to disk, replicas on other nodes and, for a recovery site, Cross Data Center Replication |
| Where it runs | Couchbase Server on your infrastructure, or Couchbase Capella, the managed service |
| From Interkey | Workload review, key design, sizing, build, migration and support from Riyadh |
What a key-value database must cover in production
The idea is simple: the application hands the database a key, such as session::8f2c or cart::customer-1042, and gets the value back. With no join and no query plan, a lookup by key stays fast as the data grows. The hard part is everything around it. Before a key-value store carries a production system, check these points:
Read more
- Speed under load. Reads and writes stay fast at peak, not only in a test with ten users.
- Scale out. Data and traffic spread over several servers, and adding a server does not mean downtime.
- Failure. When a server is lost, a replica takes over and nothing acknowledged is lost, at the durability level you chose.
- Expiry. Sessions and temporary data remove themselves after a set time.
- A way past the key. Sooner or later someone asks for "all carts abandoned yesterday". A pure key-value store cannot answer that without a second system.
How Couchbase works as a distributed key-value database
In Couchbase, the Data Service is the key-value store. Each item has a key and a value; the key is unique within its collection, and the value is a JSON document or a binary value. Couchbase's documentation sets a maximum value size of 20 MiB and a maximum key length of 246 bytes.
Memory first. Couchbase acknowledges a regular write as soon as it is in the memory of the node that holds the item, then writes it to disk. Reads of frequently used items come from memory. Couchbase's architecture documentation describes its data operations as sub-millisecond; that is the vendor's figure, and the number that matters is the one measured on your data and your hardware. When memory runs short, Couchbase ejects less recently used items from RAM, but they stay on disk and remain available.
Read more
Durability you choose per write. For data you cannot lose, such as a paid order, a write can require that a majority of nodes hold it in memory, or on disk. Couchbase notes that durable writes take longer, so the choice is made per type of data.
More than a key. Because values can be JSON, the same items can be indexed and queried with SQL++, and the Sub-Document API reads or changes one field of a large document without sending the whole value. That is the main difference from a pure key-value store. Data that needs no persistence can go in an Ephemeral bucket, held in memory only, as our distributed cache page explains.
Relateddistributed cache page
Key-value store use cases: sessions, profiles, carts and more
Each use case asks different things of the key, the expiry and the durability. This is how we usually start the design; your workload decides the final choice.
| Use case | Typical key | Expiry | Durability to consider |
|---|---|---|---|
| Login sessions | session::{session id} | Yes, matched to the session timeout | Regular writes; a lost session means signing in again |
| Customer profiles | profile::{customer id} | No | Durable writes for changes the customer made |
| Shopping carts | cart::{customer or device id} | Often, for abandoned carts | Durable writes once the cart turns into an order |
| Preferences and settings | prefs::{user id} | No | Regular writes |
| Catalogue entries | product::{SKU} | No; refreshed from the source system | Regular writes; the source system holds the master copy |
| One-time codes and tokens | otp::{request id} | Yes, minutes | Regular writes, or memory only |
Where a NoSQL key-value store fits, and where it does not
It fits when the application knows the key it needs, reads the same items many times, and must stay fast at peak: portals, mobile back ends, e-commerce and customer channels.
It does not fit when the core of the system is relational, with transactions across many entities and reports joining many tables; that work should stay on a relational engine, or be examined carefully before it moves. It is also the wrong choice when nobody, in-house or contracted, will run a distributed cluster. Our NoSQL database page sets out the four NoSQL types and when an enterprise should choose one.
Running a key-value database in Saudi Arabia
Sessions and profiles usually hold personal data, so where the store runs is a decision for your data classification, not only for your architects. Self-managed Couchbase Server runs on servers, virtual machines or Kubernetes that you operate, including 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 cluster after go-live: keys and indexes, backup and failover, upgrades and your team's questions. Remote access for support follows terms your security team sets.
What drives the cost
We print no prices: Couchbase quotes the self-managed Enterprise subscription on request, priced by the number of production nodes, and Capella is billed per node per hour. What moves the number is the same in both models:
- The working set. The share of data that must stay in memory sets the RAM, and RAM sets the node count.
- Replicas. Each replica adds memory and disk.
- A recovery site. A second cluster has its own nodes.
- Other services. SQL++ queries, indexes and search add their own nodes when they are heavy.
Interkey's work is quoted on its own lines beside the Couchbase subscription or Capella usage, so you see what each party charges.
How Interkey delivers a key-value workload
-
Workload review.
Which data is read by key, how often, the working set, how long items live and where the data must stay.
-
Key and data design.
Key patterns, collections, expiry and the durability level for each type of data.
-
Sizing and model.
Couchbase Server or Capella, nodes, memory and replicas, quoted with our work.
-
Build and test.
The cluster, security settings, backup and monitoring, then a load test on your own data and a failover drill.
-
Move the traffic.
Reads move before writes, with the old store kept as a fallback until the numbers hold.
-
Support and handover.
Support from Riyadh after go-live, and training for your team.
Questions buyers ask
What is a key-value database used for?
For data the application finds by a known identifier: login sessions, customer profiles, shopping carts, preferences, catalogue entries and one-time codes. It returns a value by its key quickly, without joins, which suits high read volumes at peak.
How fast is Couchbase as a key-value store?
Couchbase describes its data operations as sub-millisecond, and serves frequently read items from memory. That is the vendor's own figure. Latency on your system depends on item size, network, hardware and durability settings, so we measure it in a load test on your data before go-live.
If writes are acknowledged from memory, can data be lost?
A regular write is acknowledged once it is in the memory of one node, so a failure before it reaches a replica or disk can lose it. For data you cannot lose, Couchbase lets a write require a majority of nodes in memory, or on disk. Those writes take longer, so we choose per type of data.
Can a key-value database for customer sessions stay inside 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. Check where backups, monitoring data and support access go as well.
How is a Couchbase key-value cluster priced?
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 the working set held in memory and the replicas, so we size first and then quote, with our own work on separate lines.
How long does it take to move sessions or carts to Couchbase?
It depends on how many applications read the data, how the keys are designed today, your security review and the environments in scope. Sessions are often the simplest to move, since they expire on their own. We estimate after the workload review, not before.
Next
Read next
Next step
Review a key-value workload with Interkey
Tell us what the store will hold (sessions, profiles, carts or other data), roughly how many items and requests at peak, and whether the data 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