SQL interviews

What are the types of relational database?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 14 min read

A relational database is a database that stores data as tables of rows and columns, linked by shared values and queried with Structured Query Language (SQL). The types of relational database are not an official list but four axes: where the engine runs, what work it does, how it lays out data, and who owns the code. One axis decides how much data a simple query must read, and the worked numbers compute the gap.

In this article

Before you start
Why interviewers ask this
Types of relational database from first principles
Worked example
Trade-offs and edge cases
How to answer it in an interview
Common mistakes
Follow-up questions
Sources

Before you start

For the wider topic, read the SQL interview questions guide. This page needs only a picture of a table.

Why interviewers ask this

A candidate who says "MySQL is a type, PostgreSQL is a type" has listed products, not types, and the interviewer's next question exposes it. Interviewers use this question to see whether you can choose a database for a job. The choice depends on the workload, so a strong answer names the axes and says which one decides the case.

A weak answer lists product names or says "relational databases are the ones with tables." A strong answer says there is no official taxonomy, sorts engines by deployment, storage layout, workload and licensing, and gives one trade-off for each. A Staff-level answer adds that the axes combine, and that the first question to ask is what the data will be used for.

Data engineering and backend rounds also use this as a warm-up before a schema or query question.

Types of relational database from first principles

Embedded database: An embedded database is a database engine that runs as a library inside one application, so the program reads and writes the data directly, usually from a single file, with no separate server process and no network between them.
Client/server database: A client/server database is a database engine that runs as its own server process, so many programs connect to it over a network and share one central copy of the data, with the server controlling access and concurrency.
Column store: A column store is a database that keeps all the values of one column next to each other on disk instead of keeping each row together, so a query that needs a few columns can skip the rest.
Online analytical processing: Online analytical processing (OLAP) is the style of database work that runs large, read-heavy queries over many rows to calculate totals and spot trends, as opposed to recording one business event at a time.

In plain words

Think of a personal notebook and a bank branch. The notebook travels with you, one person uses it, and nothing stands between you and the pages. The bank branch holds everyone's accounts, and staff control who may touch what. The analogy breaks in one place: both of them can be fully "relational", because that word describes how the data is organized, not where it lives.

In one precise sentence: a relational database organizes data as relations, shown as tables. A type is a product's position on a choice such as embedded or client/server.

Where the word "relational" comes from

The word comes from Codd (1970). His paper introduced a model based on n-ary relations. It also introduced a normal form for data base relations. It also introduced a universal data sublanguage.

A relation here is a mathematical set of tuples. It does not mean that tables are related to each other. Codd's stated aim was that users should not need to know how data is organized inside the machine. That aim is why the same query can run on engines that store data in very different ways. A table is only one way to display a relation, and in the model the order of the rows carries no meaning. Two tables with the same rows in a different order hold the same relation.

Step 1: Where the engine runs, embedded or client/server

Where the engine runs is the first axis: embedded or client/server. SQLite's own documentation says client/server engines such as MySQL, Oracle, PostgreSQL and SQL Server aim to be a shared repository of enterprise data and emphasize scalability, concurrency, centralization and control. SQLite instead aims to give local storage to one application or device.

The same page says SQLite is not directly comparable to the client/server engines because it solves a different problem. Its database is a single file that can be copied to a portable storage stick or emailed. It also notes that many applications use SQLite as a cache of content from an enterprise relational database management system (RDBMS).

Input: a question about who shares the data. Output: embedded for one program, client/server for many. You now know the first axis; the next one is about the bytes on disk.

Step 2: Rows or columns decide how many bytes a query reads

How data is laid out is the second axis: row store or column store. A row store keeps every value of one row together, which suits reading or changing a whole record. A column store keeps every value of one column together, so a query needs only the columns it names.

Take a table of 1,000,000 rows and 10 columns, each value 8 bytes (illustrative). A query that sums one column reads 80 million bytes in a row layout, because the columns are interleaved, but only 8 million bytes in a column layout. The column layout reads a tenth of the bytes, a ratio of 10.¹ Real engines compress data and use indexes, so real savings differ. The sketch shows why the layout matters for scans.

Input: which columns a query touches. Output: how much data must be read. You now know that layout changes the cost of a scan, not the meaning of the query.

In this illustrative table a column layout reads one tenth of the bytes for a one-column query.CC BY 4.0 — source: What are the types of relational database?

Text description of the diagram

A one-column scan reads 80 million bytes in a row layout.
The same scan reads 8 million bytes in a column layout.
The column layout reads a tenth of the bytes.

Step 3: What work it does, transactions or analytics

The kind of work is the third axis. Online transaction processing (OLTP) is the style of database work that records business events, such as an order or a payment, one small change at a time. Microsoft's architecture guidance describes OLTP systems as recording business interactions as they occur. Such work relies on transactions that complete fully or not at all; the required properties are summed up as atomicity, consistency, isolation and durability (ACID), and transaction control language covers the statements that commit or undo them.

OLAP is the other side. Microsoft's page on OLAP describes it as organizing large business databases for complex calculations and trend analysis, without disrupting transactional systems. The same page says transaction databases are optimized for individual record entries, not for analysis. Totals over many rows, like the ones in conditional totals in SQL, are the typical analytical query.

Do layout and workload go together?

Layout and workload usually move together, but they are separate axes. In practice, row stores serve OLTP, because small writes touch whole records, and column stores serve OLAP, because large scans touch a few columns. The pairing is a habit of design, not a rule of the model, so a product's layout hints at its likely workload without proving it. The hybrid case is the exception. Hybrid transactional/analytical processing (HTAP) is the design in which one engine serves both kinds of work, for example by keeping a row copy and a column copy of the same data. Check each axis separately when you compare two products.

Step 4: Who owns the code, open source or proprietary

Who owns the code, open source or proprietary, is the fourth axis. It decides the license terms, who can inspect or change the engine, and who provides support. It does not decide how the engine stores data or how queries run, which is why this axis tells you least about whether a product fits a workload.

This is the axis people most often confuse with the others. "Open source" is a statement about the license, while "embedded" and "client/server" are statements about architecture. A product can be open source and client/server, or open source and embedded. Open source and commercial support are not opposites: a vendor can sell support for an open-source engine. The opposite of open source is proprietary. When you compare two products, check ownership separately from the other three axes, because it is the one that does not follow from them.

Four separate questions sort relational databases; layout and workload usually move together.CC BY 4.0 — source: What are the types of relational database?

Step-by-step description

Embedded in one program, or a shared server.
The layout sets how many bytes a scan reads.
Many small writes, or large read-heavy queries.
Open source or proprietary licensing.

Where the engine runs is the first axis: embedded or client/server.
How data is laid out, in rows or in columns, is the second axis.
The work an engine does, transactions or analytics, is the third axis.
Who owns the code, open source or proprietary, is the fourth axis.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

A small shop shows what every type has in common. The illustrative schema has customers (3 rows, with id and name) and orders (6 rows, with id, customer_id and amount).¹ A primary key is a column whose value identifies one row, so id is the key of each table. A foreign key is a column that holds the key of a row in another table, so orders.customer_id points to customers.id. This pointer is what the word "related" is often wrongly taken to mean.

SELECT c.name, COUNT(*) AS order_count, SUM(o.amount) AS total
FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;

The join pairs each order with its customer and gives 6 rows; grouping then gives one row per customer.¹ The same query runs on an embedded engine and on a client/server engine, which is the point: the axes change where and how it runs, not what the query means. To list the biggest spenders first, add a sort with undefined.

In this illustrative shop, joining orders to customers gives one row per order, and grouping gives one total per customer, 180 in all (illustrative units).
Customer	Orders	Total amount (illustrative units)
Asha	3	75
Ben	2	90
Chen	1	15
All customers	6	180

The types differ in how the six order rows sit on disk, not in what they mean. In a row layout the illustrative rows are stored record by record: (101, 1, 40), (102, 1, 25), (103, 2, 60), (104, 3, 15), (105, 1, 10), (106, 2, 30). In a column layout they are stored column by column: ids 101 to 106, then customer ids 1, 1, 2, 3, 1, 2, then amounts 40, 25, 60, 15, 10, 30.¹ A query that sums amount reads only the third list in the column layout.

Trade-offs and edge cases

The axes combine, so one product sits at one point on each. SQLite is a clear case: embedded on the first axis, and often used as a local cache of data that lives in a client/server system. The choice is therefore about fit, not rank.

Each axis answers one question, so a product is described by a choice on every axis.CC BY 4.0 — source: What are the types of relational database?

Text description of the diagram

Deployment decides how many programs share the engine.
Layout decides how many bytes a query reads.
Workload decides whether small writes or large scans dominate.
Ownership decides license and support terms.

Read the table by axis. Deployment decides how many programs share the engine. Layout decides how many bytes a query reads. Workload decides whether small writes or large scans dominate. Ownership decides license and support terms.

Each axis has two choices, decides one thing, and has a familiar example engine on each side, so a product is described by one choice per axis.
Axis	Choice	What it decides	Example engine
Deployment	Embedded	One program owns the data	SQLite
Deployment	Client/server	Many programs share one copy	PostgreSQL or MySQL
Layout	Row store	Whole-record reads and writes are cheap	PostgreSQL or MySQL
Layout	Column store	Scans over a few columns are cheap	A columnar warehouse engine
Workload	OLTP	Many small writes	PostgreSQL or MySQL
Workload	OLAP	Large read-heavy queries	A columnar warehouse engine
Ownership	Open source	Anyone may inspect the code	PostgreSQL, MySQL or SQLite
Ownership	Proprietary	The vendor controls the code	Oracle Database or SQL Server

Edge cases follow. First, a single engine may offer several modes or extensions, so a label describes its common use, not every use. Second, the real cost of a layout depends on compression, indexes and the query: column compression can widen the gap well beyond tenfold, while an index or a query over most columns can narrow it, so the tenfold figure belongs to this illustration only. Third, the transactional and analytical styles are often split into two systems, with data copied from one to the other, which is the flow Microsoft's OLAP guidance draws. Fourth, a database that is not relational, such as one that stores documents, is a different family and not another type of relational database.

Two more cases come up in design rounds. The first is scale-out. A single-node engine keeps the whole database on one machine, while distributed SQL shards and replicates one logical database across several machines and keeps SQL and transactions, usually at the cost of extra coordination between them. The second is who runs the engine. Any client/server engine can be self-hosted, run by your own team, or cloud-managed, run by a provider. That changes who operates it, not the data model.