Document database: JSON documents with SQL++, indexes and ACID transactions

In a relational database a customer with three addresses and five orders lives in three tables, joined at every read. In a document store the same customer is one document: its fields, an array of addresses and, where the application reads them together, a summary of recent orders. Each document carries its own structure, so a new field arrives with the next release of the application, without a schema migration.

Relatedguide to SQL and NoSQL

Couchbase keeps documents in collections, each reached by its key, and a key lookup is the fastest path. Where the application needs one field, the Sub-Document API reads or changes that path alone.

Where the access is not by key, SQL++ does the work. It reads like SQL, extended for nested objects and arrays. "Close to SQL" is not "identical", so queries are redesigned for the document model rather than copied across. SQL++ depends on indexes: a primary index on the document key, and secondary indexes on the fields your queries filter and sort on. The Search Service adds full-text, geospatial and range search, and vector indexes support similarity search over embeddings.

A document model usually fits:

• customer and citizen profiles served to portals and mobile apps at high concurrency;
• product and service catalogues whose attributes differ by category;
• orders, bookings and applications read and updated as one record;
• field and mobile applications that also need offline sync (see mobile offline sync).

It usually does not fit:

• heavy ad-hoc reporting and cross-entity analysis, which belong on an analytical platform;
• a core that is truly relational, where money, stock or entitlements change together in most operations;
• an estate where nobody, in-house or contracted, will own a distributed database in production.

A cheaper first step is often to keep the system of record relational and serve one busy read path from a document store kept in step with it.

Relatedmobile offline sync

Couchbase Capella is billed per node per hour, scaled by each node's vCPU and RAM; Interkey sells it, so one quote can cover Capella credits and our work. Self-managed Couchbase Server is a subscription priced by the number of production nodes, quoted alongside our work. Our effort follows the number of services that touch the data, how far the current schema is from a document model, and how long both systems run side by side. Durations are estimated after the workload review.

RelatedCapella or self-managed pageSaudi Data and AI Authority (SDAIA)