Couchbase · In-memory database
In-memory database: the speed of memory, without losing the data
An in-memory database answers most reads from RAM instead of disk, so applications stay fast under heavy load. The risk is that memory is lost on a restart. A memory-first database keeps the speed and also writes every change to disk. This page explains how that works, how it differs from a pure cache, and how Interkey sizes, builds and supports Couchbase as an in-memory NoSQL database in Saudi Arabia.
Orientation
At a glance
The page in one table, before the detail.
- What it is
- A database that serves most reads from memory
- Memory-first, not memory-only
- Couchbase also writes data to disk, so a restart does not empty it
- How it differs from a cache
- A cache holds copies; a memory-first database is the system of record
- Where it can run
- Couchbase Capella, including the Dammam region, or self-managed Couchbase Server
- How it is bought
- A memory sizing first, then a quotation per programme
In short, for executives
- What it is: the data an application reads most is kept in RAM, so answers do not wait for disk.
- The common worry: memory-only data can be lost on a restart or a failure.
- The memory-first answer: Couchbase serves reads from memory and writes every change to disk, with replicas on other nodes.
- Where it does not fit: a cache that already meets the need, or a strictly relational, transactional core.
What an in-memory database is, and why persistence matters
Every database keeps some data in memory. A database is "in-memory" when memory is where the work happens: the data an application asks for most is already in RAM, and reads are answered from there. Disk keeps the data safe; it is not where each request is fetched from.
When a portal asks for the same records thousands of times a minute, waiting for disk on each request costs time and capacity; memory keeps response times steady as load climbs. The next question is what happens on a restart:
Read more
- Memory-only. Data lives in RAM and nowhere else. Fast, and gone if the memory is lost: acceptable only for data the application can rebuild.
- Memory-first with persistence. Data is served from memory, written to disk and copied to other servers. Hot data is just as fast, and the database can be the system of record.
The term in-memory data grid usually means software that pools the memory of many servers into one store, often in front of another database. The same decision applies: where does the durable copy live?
Pure cache, memory-first database or disk-first database
Three designs that keep data in memory, compared by what they promise when something fails.
| Question | Pure cache (memory only) | Memory-first database (Couchbase buckets) | Disk-first database |
|---|---|---|---|
| Where reads are served from | Memory | Memory for the hot data; disk for data ejected from memory | Disk, with a buffer of recent pages in memory |
| Where the data of record lives | Somewhere else: the cache holds copies | In the database itself, in memory and on disk | On disk |
| After a restart | Empty until refilled, and the database behind it takes the load | Data reloads from disk; by default requests are served while it loads | Data is on disk; the buffer warms up with use |
| When a server is lost | Its share of the cache is gone | Replicas on other nodes take over | Depends on the replication set up |
| Queries beyond a key | Usually none | SQL++, search and analytics services on the same data | Full query language |
| What to watch | Stale copies and two systems to run | Memory sizing for the working set | Read latency under heavy, repeated load |
If you need a cache in front of a database you keep, our distributed cache page covers that case, including memory-only buckets.
What a memory-first database must get right
These questions decide whether an in-memory NoSQL database is safe for production:
Read more
- When a write counts as done: in memory, on disk, or on more than one server. Different flows need different answers.
- What leaves memory when it fills, and what that costs the next read.
- How it comes back after a restart without turning a routine patch into an outage.
- How it survives a lost server: copies on other nodes, and at another site for disaster recovery.
- How you query it. Lookups by key soon become queries by a field; a key-value only design pushes that work into the application.
- How much memory it needs. The working set, the data read often enough to stay in memory, sets the RAM, not the total volume.
How Couchbase works as a memory-first database
Couchbase is a distributed NoSQL database. Interkey is a Couchbase technology partner and sells Couchbase Capella. From Couchbase's documentation:
- An integrated, managed cache. The caching layer is built into the Data service and managed automatically; there is no separate cache to keep in step.
- Memory, then disk. A regular write is acknowledged once it is in memory on the node holding the active copy, then queued for disk. Couchbase calls regular writes asynchronous.
- Durability when a flow needs it. A write can require majority (in memory on most Data service nodes), majorityAndPersistActive (also on disk on the active node) or persistToMajority (on disk on most nodes).
- Ejection keeps the data. Near the memory quota, data is ejected from memory but stays on disk. Value-only ejection keeps keys and metadata in memory; full ejection removes the whole document and saves more memory.
- Warmup. A restarted node reloads data from disk; by default the bucket serves requests while the rest loads.
- Two storage engines. Couchstore suits data that largely fits in memory; Magma is designed for large data sets that do not, and needs a far smaller share of the data in memory.
Read more
The same documents are fetched by key and queried with SQL++, so the in-memory store is also the operational database. See our key-value store page for lookups by key and the NoSQL database page for the four types of NoSQL. Couchbase publishes its own performance figures; the ones that matter are measured on your data, in a proof of concept.
Relatedkey-value store page
Where an in-memory database earns its place in Saudi Arabia
In the Kingdom the need usually appears as a system under read pressure it was not designed for:
- Portals at national scale, where the same profile and eligibility records are read again and again at a launch or a deadline.
- Sessions and tokens checked on every request, which must survive a restart so users stay signed in.
- Catalogues, prices and offers read far more often than they are written.
- Mobile back ends answering many small reads per screen.
Read more
Two Saudi questions come first. Where may the data live? Many organisations must keep certain data inside the Kingdom under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa); disks, replicas and backups all count. Who will run the cluster after go-live? Support comes from Riyadh, from Interkey engineers who work in Arabic and English.
Relatednca.gov.sasdaia.gov.sa
Capella or self-managed Couchbase Server
Couchbase Capella is the vendor's managed service on AWS, Google Cloud or Microsoft Azure; as of 2 November 2026 its published regions include Google Cloud's Dammam region (me-central2). Self-managed Couchbase Server runs on infrastructure you control, such as your own data centre in the Kingdom. A region in the Kingdom settles where the cluster's data sits, not where backups or logs go. Our Capella or self-managed page compares the two.
RelatedCapella or self-managed page
How Interkey delivers an in-memory database project
-
Workload review.
Read and write rates, the working set, durable-write flows, peak load and the residency rule. "Keep the cache you have" is a legitimate outcome.
-
Memory sizing.
RAM per node from the working set and replicas, the storage engine and ejection policy.
-
Data modelling.
Keys and documents shaped by how the application reads them, with indexes for queries beyond a key.
-
Build and test.
Capella in the agreed region or Couchbase Server on your infrastructure, then a load test, a restart and a failover drill.
-
Move the workload.
Data synchronised from the current system, usually with iblync, Interkey's own product; reads move before writes.
-
Operate or hand over.
Tuning and upgrades under a written managed-services scope, or a documented handover.
What drives the cost of an in-memory database
We publish no price or duration; both depend on the workload. Memory moves the number most:
- The working set, not the total data, sets the RAM.
- Replicas multiply memory and disk.
- The storage engine changes the memory-to-data ratio.
- A recovery site adds a second cluster.
Read more
Capella is billed per node per hour, scaled by each node's vCPU and RAM; self-managed Couchbase Server is a subscription priced by production nodes. Our work is quoted on its own lines: review and sizing as a fixed piece of work, the move priced by the workloads in scope.
Questions buyers ask
Will we lose data if an in-memory database server restarts?
Not with Couchbase buckets: data is written to disk as well as held in memory, replicas sit on other nodes, and a restarted node reloads from disk. Memory-only buckets do lose data, so keep them for data you can rebuild.
Do we still need a separate cache in front of Couchbase?
Usually not for the data Couchbase holds, because its caching layer is built in. A cache that serves another database well can stay.
How much RAM does an in-memory database need for our data?
It depends on the working set, replicas and the storage engine. We size it from your own figures and test it under load before anything is ordered.
Can an in-memory database for a Saudi portal keep its data inside the Kingdom?
Yes. Couchbase Server can run in your own data centre in the Kingdom, and as of 2 November 2026 Capella's published regions include Google Cloud's Dammam region. Check backups and logs too.
How is a memory-first Couchbase cluster licensed in Saudi Arabia?
Capella is billed per node per hour, and Interkey sells it. Self-managed Couchbase Server is a subscription by production node, quoted alongside our work.
How long does it take to move a workload onto a memory-first database?
It depends on how many services use the data, how far the model is from documents and how long the parallel run lasts. We estimate it from the workload review's plan.
Next
Related pages
Next step
Size an in-memory database for your workload
Tell us what the application serves, how much data it holds, how much is read often, which writes must never be lost and where the data must be hosted. We will reply with a first sizing.
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