Data platform · Plain guide
Types of databases: what they are, what they are made of, and when each one fits
This guide explains the types of databases in plain words: what a database is, what it is made of, and the six main types in one table with where each fits. It then covers what organisations in the Kingdom face: systems with more than one type, data moving between types, and NoSQL at scale.
Published 9 min read
Orientation
At a glance
The whole page in one table, before the detail.
- What a database is
- An organised store of data, run by software that saves it, returns it, protects it and controls who can reach it
- Its components
- Data, data model, engine, query language, indexes, transaction log, access control, backup
- The six main types
- Relational, document, key-value, graph, time-series and in-memory
- The two big families
- Relational databases, and NoSQL databases, which cover most of the other types
- How a type is chosen
- From how data is read and written, the transactions needed, the load, and where the data must reside
- Where Interkey helps
- Moving data between types with iblync, and NoSQL at scale with Couchbase
In plain words
- No single type suits everything. Each of the types of databases answers some questions well and others badly.
- Relational databases still run most business systems. Other types appear when records change shape, load grows, or relationships become the data.
- Most organisations run more than one type at once. The practical question is also how data moves between them without stopping the business.
- In Saudi Arabia one question comes first: where the data may reside, and who will run the database.
What a database is, and the components of a database
A database is an organised store of information, run by software called a database management system. That software saves the data, returns it when an application asks, stops two users' writes from colliding, and decides who may see what.
Every database, whatever its type, is built from parts that do the same jobs, even when their names differ:
Read more
- The data itself: orders, customers, device readings.
- The data model: the shape the data is stored in, whether tables with fixed columns, JSON documents, key-value pairs, or nodes and relationships. This is the main difference between the types.
- The engine: the software that writes, reads and stores the data, in memory, on disk or both.
- The query language: how an application asks for data, such as SQL in relational databases, or other languages elsewhere.
- Indexes: structures that let the engine reach the record it needs without reading everything.
- The transaction log: a record of every change before it is applied, so the database returns to a sound state after a failure.
- Access control: accounts, roles, encryption.
- Backup and replication: copies elsewhere, to restore after a mistake or keep running when a server stops.
The six main types of databases, and when each one fits
These are the types that appear most often in organisations' systems. Many products today combine more than one type in a single platform.
| Type | What it stores | When it fits | Watch for |
|---|---|---|---|
| Relational | Tables with fixed columns, joined at query time with SQL | Finance, HR, inventory: any operation that changes several records that must succeed together | Structure changes need planning; growth usually means a bigger server |
| Document | Self-contained records, usually JSON, read and written whole | Customer profiles, product catalogues, orders, case files, and content whose fields change with each release | Copying tables into documents one-to-one usually performs worse; design each document around how it is read |
| Key-value | A value retrieved by a unique key | Sessions, caching, user preferences, and any fast lookup by a known identifier | Looking up by anything other than the key needs another mechanism |
| Graph | Nodes and the relationships between them | Relationship networks, fraud rings, recommendations, supply-chain tracing | A tool for a specific purpose: strong on connections, rarely the main system of record |
| Time-series | Readings ordered by time, appended continuously | Sensor and meter readings, system metrics, prices that change every moment | Needs a clear retention policy, because the volume grows every day |
| In-memory | Data held in memory rather than on disk first | Very frequent reads that must return in a fraction of a second, and live counters | If the data is not also written to disk, it can be lost on restart |
Narrower types exist too: wide-column stores for very large write volumes, full-text search engines, and vector indexes for search by meaning in AI applications. Whatever the type, test the product against the queries your system really runs.
Relational databases and NoSQL databases: the two big families
The six types fall into two families. The first is relational databases: data sits in tables with fixed columns, the links between them are keys, queries are written in SQL, and transactions guarantee that an operation changing several records either completes or is undone in full. They remain right for most business software, because money, stock and payroll are relational at heart.
Read more
The second is NoSQL databases, a broad name for any database that stores data without fixed tables: document, key-value, graph and wide-column. Most share three traits: they do not require a fixed structure in advance, they store data in the shape it is read, and they were designed to spread data and load across a cluster of servers. Beyond that, products differ: some offer SQL-like queries and full transactions, others do not.
The detailed comparison has its own page: SQL vs NoSQL: how to decide for an enterprise workload. It lists what to measure, and when staying relational is right.
RelatedSQL vs NoSQL: how to decide for an enterprise workload
How to choose between types of databases: questions to ask first
Read each question against your system as it runs today, not as you expect it to run. The answer points to a type; it does not settle the product.
| Question | If the answer is yes | What to check next |
|---|---|---|
| Does one operation change several linked records that must succeed together, such as an accounting entry? | Relational, or a NoSQL product with full transactions | The transaction scope the product really offers |
| Do a record's fields change with each release, or differ by customer type or data source? | A document database | How documents will be designed, and queries rewritten |
| Is most data read by a known identifier, with a very fast response needed? | Key-value, or an in-memory database | Whether the data is also written to disk, and what happens after a restart |
| Are the relationships between items what you search, rather than the items? | A graph database beside the main system | How it stays consistent with the main system |
| Does data arrive as time-ordered readings without pause? | A time-series database | The retention period, and how old readings are summarised |
| Does peak load exceed what one server can carry? | A platform that spreads data across servers, usually NoSQL | Who runs the cluster, and how failover is tested |
| Must the data stay inside the Kingdom? | The type does not decide this; the deployment does | The region or data centre, plus backups, replicas and logs |
Answers pointing to more than one type are normal: large systems usually pair a relational database for core records with another for frequent reads or changing records.
Types of databases in Saudi organisations: more than one type in one system
Organisations in the Kingdom rarely start from nothing. Usually a relational system built for an internal application now also serves a portal, a mobile app and analysts, with seasonal peaks. A second type appears, with two practical questions.
First: how does data move from one type to another without stopping the business? A table becomes a document, keys change, and applications move service by service, so both systems must stay consistent until cut-over. That is what iblync does, Interkey's own platform for migrating and replicating data between systems that were not designed to exchange it: a one-time or phased load, continuous replication including bi-directional synchronisation, and throttling so production keeps its capacity. Our database migration services page sets out how a project runs from assessment to cut-over.
Read more
Second: where may the data reside? Many organisations must keep certain classes of data inside the Kingdom, under the controls of the National Cybersecurity Authority (NCA) and the Personal Data Protection Law overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA). That decides the deployment, a cloud region in the Kingdom or your own data centre, and it covers backups, replicas and logs too. Which rules apply to you is for your compliance owner to confirm from the authorities' own texts.
Interkey's team works from Riyadh, with engineers who speak Arabic and English, so data-model reviews happen in the language your business owners use.
Relatediblyncdatabase migration servicesNational Cybersecurity Authority (NCA)Saudi Data and Artificial Intelligence Authority (SDAIA)
NoSQL databases at scale: where Couchbase fits, and where it does not
When a workload is document or key-value shaped and grows beyond what one server can carry, Interkey works with Couchbase. Interkey is a Couchbase technology partner and sells Couchbase Capella. According to Couchbase's own documentation:
- Each item is a JSON document or a binary value with a unique key, fetched by key or by query, so the document and key-value types sit in one platform.
- Documents are queried with SQL++, a language based on SQL, so development teams start from familiar ground.
- ACID transactions are available through SQL++.
- Data is held in memory and on disk, so the platform serves frequent fast reads without losing data on restart.
Read more
It can run as Couchbase Capella, the managed service on AWS, Google Cloud or Microsoft Azure, or as Couchbase Server on infrastructure the organisation runs, including its own data centre in the Kingdom. Our page on the document database covers that type in more depth.
Where it does not fit. Couchbase is not a graph database, and it does not replace an analytical reporting warehouse. If the current relational database carries its load, staying is usually right, and we will say so. The Couchbase page has the full table of where it fits and where it does not.
Relateddocument database
How Interkey helps you choose a type of database
We start with the workload, not the product: how the system reads and writes its data, the transactions it needs, its peak load, and where the data must reside. The assessment may conclude that you should stay where you are.
If a change is right, we design the data model with your teams, build the platform where agreed, move the data while the old system runs (with iblync where it fits), and switch applications service by service after a rehearsed cut-over. After go-live we operate under a written scope, or hand over full documentation.
We do not publish fixed prices or durations. The assessment is a defined piece of work, migration is priced by the systems in scope, and Couchbase or iblync licensing is quoted separately for each project.
Questions buyers ask about types of databases
How many types of databases are there, and which are the most common?
There is no fixed number, but six types appear most often in organisations' systems: relational, document, key-value, graph, time-series and in-memory. The non-relational types are usually grouped under the name NoSQL.
What are the basic components of any database?
The data, the data model it is stored in, the engine, the query language, indexes, the transaction log, access control, and backup and replication. The types differ from one another mainly in the data model.
Can our organisation run more than one type of database at the same time?
Yes, and in large systems that is normal: a relational database for core records and another for what is read very often or changes shape. What matters is being clear which database owns each record, and how data stays consistent between them.
Does the type of database change where our data can reside in Saudi Arabia?
No. Data residency is set by the deployment, not the type: a cloud region inside the Kingdom or a data centre the organisation owns. That includes backups, replicas and logs. Your compliance owner confirms which rules apply to you.
How long does moving a system from a relational database to a NoSQL database take?
It is estimated per project. The main drivers are how many services read and write the data, how far the current tables are from a document model, and how long the parallel run lasts before writes move. The assessment produces a plan with an estimate and its reasons.
Does Interkey support database projects from inside the Kingdom, and how are they priced?
Yes, the team works from Riyadh in Arabic and English. Each project is quoted: the assessment is a defined piece of work, migration is priced by the systems in scope, and Couchbase or iblync licensing is quoted separately.
Next
Related pages
Next step
Find out which type of database fits your system
Tell us what the system does, the database it runs on today, where it struggles and where the data must reside. We reply with a written view on the type that fits, and whether the system needs to change at all.
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