As I slowly, and reluctantly, try to make a comeback to microblogging sites after many years out, I stumbled across the following tweet in my very first days there:

For a long time, I used sharding and partitioning as interchangeable concepts, almost like synonyms, even though in my head sharding has always been an industry-crafted term that heavily implied scaled-out multi-node architectures while partitioning was the more general concept above it. But to my surprise, many replies to this particular tweet were saying essentially this:

“Partitioning splits data within a single server, while sharding distributes data accross multiple servers to scale horizontally.”

The same adage, expressed by different individuals, indicated a more solid, ingrained or established definition that went straight under my radar this whole time! I was mesmerized… Maybe something changed while I was out, hahah? Maybe I didn’t get the memo back then?

In a previous life, this small discordance would immediately engage me on a real-life version of that famous XKCD cartoon:

But jumping headfirst into heated discussions for countless hours in a medium of limited expressiveness feels so dated, tiresome and, well, wasteful… Therefore, I decided to hit the respectable literature and products’ documentations, so that I could challenge my own (mis-)understandings, fill in the gaps, and maybe write an educational material in the process.

And for what’s worth, a genuine and relevant doubt unfolded itself into a nice oportunity to review some crucial concepts in databases and distributed systems! 😄

To kickstart the discussion, let’s see how this kind of intermingling between partitioning and sharding definitions can be witnessed nowadays on many real-world systems’ terminologies. In the sample listing of Table 1, “partition” is being used to describe both single-node systems (e.g. PostgreSQL) and multi-node systems (e.g. DynamoDB), with a few other synonym terms (e.g., tablet and region) thrown into the mix! Therefore, the assertion that partitions are only for single nodes just doesn’t stand up to a closer look. :smiling_face_with_tear:

Table 1 - Real world systems’ terminologies

Then why do people say “partitioning = one machine”?

Probably because of the commercial database vendors’ terminology and the dot-com era’s web companies. The “partitioning = single node, sharding = multiple nodes” distinction seems to have emerged from these two different, but related, arenas, as we should see shortly.

The commercial DBMS’ prism lens

On one side, we had commercial DBMSs popularizing and strongly supporting, to this day, table partitioning as a product feature for subdividing one logical table into physical pieces under a single database installation. Oracle 10g describes partitioning as decomposing a large table or index into smaller pieces called partitions. PostgreSQL uses essentially the same product-level vocabulary: “splitting what is logically one large table into smaller physical pieces.” We also had other instances of this trend in products like SQL Server, MySQL, and Db2, for example.

So, when a DBA in the 2000s said that “we partitioned the orders table”, they usually meant a native DBMS feature like this:

These features often look like:

CREATE TABLE orders (...)
PARTITION BY RANGE (timestamp);

The web-scale systems’ prism lens

On the other side, also during the 2000s, web companies faced a somewhat different problem due to the exponential growth of the web: a single database server couldn’t support all their users’ data and load, so web companies started using the term sharding specifically for describing the distribution of subsets of the application’s data over multiple database servers. Sharding was the operational term for companies like eBay, Yahoo!, Facebook, among others. An old engineering post by Flickr summarises how many companies operated back in the day:

“Sharding (aka data partioning) is how we scale Flickr’s datastore. Instead of storing all our data on one really big database, we have lots of databases, each with some of the data, and spread the load between them.”

Back in the day, when an eBay/Flickr/Facebook/Google engineer said that “we sharded users”, they usually meant something like:

And later, during the 2010s, the “sharding” term solidified through the success of NoSQL systems such as MongoDB and Riak, for example. MongoDB documentation states that “Sharding is a method for distributing data across multiple machines.”

All of this produced an extremely convenient practitioner distinction:

Partitioning = split a table inside the database. Sharding = split the database across machines.

There was a sociotechnical reason for the distinction: those two activities had radically different operational implications and consequences, so having two words was useful. The distinction is pedagogically convenient and historically understandable, but people eventually started treating the convention as if it were the formal definition. That is, the problem arose when the useful practitioner distinction became retroactively interpreted as a definition of partitioning itself, something that many decades of study and research on databases never supported.

Nevertheless, there are examples in the industry that acknowledge the relation between partitioning and sharding. Vitess documentation is more explicit and intellectually cleaner, as it does not treat partitioning and sharding as mutually exclusive:

“Sharding is a method of horizontally partitioning a database to store data across two or more database servers.”

And Oracle’s sharding documentation has a section literally titled “Sharding as Distributed Partitioning”, showing that sharding is based on horizontal partitioning of data across multiple independent physical databases. It further says that table partitions within a shard are the same kind of partitions used in a non-sharded Oracle database.

But things are far from being settled. Google Cloud currently has explanatory material saying that partitioning keeps pieces on the same server whereas sharding places them on different servers. Its own explainer on data sharding draws the line almost as cleanly as the tweet that started all this:

“Sharding is a specific type of horizontal partitioning where the data pieces are distributed across completely different servers… Partitioning involves splitting a large table into smaller, more manageable pieces (like splitting a log table by month) but keeping them on the same server instance.”

But a few paragraphs further down the very same page, it describes Spanner — a “distributed SQL database” — as offering “a ‘no-sharding’ experience” that “automatically shards data and balances load across regions,” and credits Bigtable’s tablet splitting as “automatic sharding” too. And the same Google ecosystem also talks about geo-partitioning, which “lets you further segment and store rows in your database table across different instance configurations,” and about distributed Spanner instance partitions, which are explicitly regional or multi-region constructs, each with their own compute capacity, spanning multiple servers by design. So even industry terminology isn’t internally uniform — sometimes not even within the same web page!

Therefore, saying “partitioning means single node” without qualification is historically and technically misleading. A more precise statement is:

“In some RDBMS discussions, partitioning conventionally means intra-database table partitioning, while sharding means horizontal partitioning across database instances.”

And even though partitioning was never inherently single-node in the literature, Silberschatz, Korth & Sudarshan[3] acknowledge that partitions may have such a narrower meaning:

“We also note that several database vendors use the term partitioning to denote the partitioning of tuples of a relation \(r\) into multiple physical relations \(r_1, r_2 ,…, r_n\), where all the physical relations \(r_i\) are stored in a single node. The relation \(r\) is not stored, but treated as a view defined by the query \(r_1 \cup r_2 \cup … \cup r_n\). Such intra-node partitioning of a relation is typically used to ensure that frequently accessed tuples are stored separately from infrequently accessed tuples and is different from horizontal partitioning across nodes.”

Kleppmann and Riccomini[4], who devote no less than a whole chapter to sharding, also explain the nonconformity of the nomenclature surrounding sharding and partition:

“What we call a shard in this chapter has many names depending on which software you’re using. It’s called a partition in Kafka, a range in CockroachDB, a region in HBase and TiDB, a vBucket in Couchbase, a vnode in Riak, a token-range in Cassandra, and a tablet in Bigtable, YugaByteDB, and ScyllaDB, to name just a few. Some databases treat partitions and shards as two distinct concepts. For example, in PostgreSQL, partitioning is a way of splitting a large table into several files that are stored on the same machine (which has several advantages, such as making it very fast to delete an entire partition), whereas sharding splits a dataset accross multiple machines[1,2]. In many other systems, partitioning is just another word for sharding.“

So far, we have two reputable sources stating that:

• a) there is no clear separation between the concepts of partitioning and sharding, either in industry or academia, up to the point that the two terms are often used as synonyms (phew! 😅);
• b) what is usually known as a partition can also mean something confined to a single node!

How has academia treated these concepts?

To really understand how academia has dealt with these concepts for decades, we should focus on their vernacular and their assumptions first. It may even come as a surprise to newcomers that what the practitioners usually call “partitioning” is frequently referred to by respectable sources in the literature as “fragmentation”. And the terminology mismatch doesn’t stop there, as we have words like “sites” for denoting nodes or computers, for example.

In addition to that, it was already mentioned that classical and modern database literature doesn’t restrict the applicability of data partitioning to an intra-node setup. Also, data partitioning can be applied to either parallel or distributed database systems (and arrays of disks too!). As explained by Özsu and Valduriez[2], the main reasons and objectives for fragmentation in distributed versus parallel databases are slightly different. For example, data localization is not that much of a concern in parallel DBMSs since the communication cost among nodes is much less than in geo-distributed DBMSs.

Fragmentation, Allocation and Replication

The academic distributed/database literature cleanly separates the concepts of Fragmentation, Allocation, and Replication (or should we say “The Good, The Bad and The Ugly”?) as three related but orthogonal axes of classification (see Figure 1), with the following definitions:

Figure 1 - Three axes of classification

1. Partitioning

Ramakrishnan and Gehrke[1] define fragmentation (i.e., partitioning) as:

“Fragmentation consists of breaking a relation into smaller relations or fragments and storing the fragments (instead of the relation itself), possibly at different sites. In horizontal fragmentation, each fragment consists of a subset of rows of the original relation. In vertical fragmentation, each fragment consists of a subset of columns of the original relation.”

So, this definition can be summarised in a short paragraph (or tweet!) as:

Partitioning means dividing a dataset into disjoint subsets according to some rule.

The partitions (fragments) are defined as the logical unit of division and distribution in a database, so that a relation \(R\) is split into (usually) disjoint \(P_i\) partitions over one or more attributes (called partitioning attributes, partitioning keys or shard keys) of \(R\), such that:

This definition doesn’t conditionate partitioning of data to its placement, be it local or distributed among nodes. Those partitions \(P_{i}\), for \(i = \{1,.., n\}\) could either reside on a single node,

or be distributed among various nodes,

or even be a combination of single and multi-node, but, in any case, they are still partitions.

1.1. Partitioning Strategies

As seen in Ramakrishnan and Gehrke’s definition, data partitioning is further divided into horizontal and vertical partitioning, and this is also defined by Özsu and Valduriez[2]:

“Relational tables can be partitioned either horizontally or vertically. The basis of horizontal fragmentation is the select operator where the selection predicates determine the fragmentation, while vertical fragmentation is performed by means of the project operator. The fragmentation may, of course, be nested. If the nestings are of different types, one gets hybrid fragmentation.”

Regardless of the partitioning strategy applied, the fragmentation should guarantee that the database doesn’t undergo semantic changes during the process and ensure the reconstructibility property, that is, still be able to recover the original relation \(R\) from its fragments. Although not always present, it is usually desirable for the fragmentation technique to have a set of properties during decomposition of the tuples among partitions, as listed below:

• Completeness: for any tuple \(t\) of a relation \(R\), \(t\) will be in at least one partition, that is, no information is lost. This is based on the selection and projection predicates chosen;
• Reconstructibility: it should be possible to reconstruct the original relation \(R\) by using the UNION operator (for horizontal fragmentation) or the OUTER UNION operator (for vertical fragmentation);
• Disjointness: there’s no intersection between two partitions under horizontal partitioning, and vertical partitions only share the unique key attribute (so it’s possible to reconstruct the original relation);

Horizontal Partitioning

Horizontal Partitioning splits the relation \(R\) into (usually) disjoint subsets of the tuples of the original relation, specified by a condition \(C\). The horizontal partitioning can be expressed as the relational algebra’s SELECT (\(\sigma\))² operation:

Condition \(C\) is a predicate often composed of a single attribute – with the form \(R.\text{attr} \mathrel{\mathbf{op}} \text{value}\), where \(R.attr\) is an attribute of relation \(R\), op is a conditional operator (e.g., =, \(<, \ge\)), and value is a literal.

Suppose we have the following PROJ table and apply conditions \(C_{1} = BUDGET < 250000\) and \(C_{2} = BUDGET \ge 250000\), this will produce two horizontal partitionings as below:

Elmasri and Navathe define an interesting property of horizontal partitioning:

“A set of horizontal fragments whose conditions \(C_1, C_2, … , C_n\) include all the tuples in R—that is, every tuple in R satisfies (\(C_1\) OR \(C_2\) OR … OR \(C_n\))—is called a complete horizontal fragmentation of R. In many cases a complete horizontal fragmentation is also disjoint; that is, no tuple in \(R\) satisfies (\(C_i\) AND \(C_j\)) for any \(i \neq j\).”

And to reconstruct the relation R from a complete horizontal fragmentation, it is necessary to apply the UNION operation to the partitions.

It’s also important to observe that depending on the \(C_i\) conditions of the horizontal partitioning, this may result in an uneven data distribution among the partitions (data skew), as illustrated by the image below where we split the horizontal fragments by the Dno column. This can potentially create hot spots and performance bottlenecks, with some partitions overloaded while others are mostly idle.

Both Silberschatz et al and Özsu and Valduriez mention that horizontal partitioning is widely used for parallel and distributed database systems because of its inherent opportunities for both interquery and intraquery parallelism³.

Horizontal Partitioning Strategies

Horizontal partitioning can be further divided into different schemes to split the rows into disjoint subgroups:

1. Round-Robin Partitioning

For n processors, the ith tuple is assigned to the processor \(i \bmod n\). This technique is ideally suited for applications that read the entire relation sequentially for each query. As far as the literature goes, it is especially used in RAID disk arrays.

2. Hash Partitioning

There’s a hash function that maps a key value to a partition number. This keeps data evenly distributed even if data grows and shrinks over time. It is best suited for point queries based on the partitioning attribute, but it’s also useful for sequential scans over the entire relation or range queries on the partitioning attribute. If the hash function is good, the number of tuples in each node is roughly the same, i.e. \(\frac{1}{N}\), for \(N\) nodes. Nevertheless, it is not well suited for point queries on nonpartitioning attributes.

3. Range Partitioning

This strategy partitions tuples by the range of their key values. Tuples are sorted (conceptually), and n ranges are chosen for the sort key values so that each range contains roughly the same number of tuples. We assign contiguous attribute value ranges to each node. Given a set of nodes \(N_1, N_2, ..., N_n\), we choose a partitioning attribute \(A\) and a partitioning vector \([v_1, v_2, ..., v_{n-1}]\) such that, if \(i < j\), then \(v_i < v_j\). The relation \(R\) is partitioned as follows for a tuple \(t\), where \(t[A] = x\):

Primary and Secondary Horizontal Partitioning

A primary horizontal partitioning is a partition defined by predicates on root tables (source tables): tables that exist as independent entities, without any Foreign Key (FK) pointing to it, like, for example, the CUSTOMER table in the example below. This table can be partitioned by its range of IDs, for example.

On the other hand, derived horizontal partitioning is the partitioning of a relation that results from predicates being defined by another relation (that is, the table depends on one or more other tables to exist and have uniqueness). Tables like ORDERS and INVENTORY are examples of such tables, so that we can partition them according to how their referenced parent table (e.g., CUSTOMER) was already partitioned, keeping related rows co-located on the same fragment for faster joins.

Vertical Partitioning

Vertical partitioning splits a relation \(R\) into partitions each containing a subset of \(R\)’s attributes (columns). In other words, it divides a relation “vertically” by columns. This particular kind of data partitioning was successfully implemented by column-store DBMSs like MonetDB/X100, Vertica, Snowflake and DuckDB, for example, as well as columnar open data formats and OLAP query engines.

Vertical Partitioning can be expressed as the relational algebra’s PROJECT (\(\pi\)) operation:

where \({L_i}\) is the list of attributes (columns) of \(R\), for \(i = 1,..., N\), where \(N\) is the number of attributes of relation \(R\).

Suppose that our PROJ table is split by two lists of attributes, \(L_{1} = \{PNO, BUDGET\}\) and \(L_{2} = \{PNO, PNAME, LOC\}\)

As we can see in the example above, PNO, the Primary Key (PK) of the PROJ table is duplicated on the two fragments – \(PROJ_{1}\) and \(PROJ_{2}\). This is not a coincidence, but a conscious distributed database design decision so that we are able to reconstruct the original relation \(R\) from its vertical fragments by using an OUTER UNION operation. In other words, our database design has a lossless-join property.

A vertical partitioning is said to be a lossless-join decomposition if it’s always possible to reconstruct the original relation \(R\) from its vertical fragments \(L_1, L_2, ... L_n\). This is more succinctly expressed in relational algebra as:

That is, the natural join of the projection results exactly in the original relation \(R\). Conversely, if the same natural join computation results in a superset of the original relation then the decomposition is said to be lossy. This can be expressed succinctly in the relational algebra as:

Figure 2.2 in Georgiev’s thesis[6] shows examples of a lossy (a) and a lossless (b) decomposition.

Finally, Ramakrishnan and Gehrke state the following about vertical partitioning:

“To ensure that a vertical fragmentation is lossless-join, systems often assign a unique tuple id to each tuple in the original relation, as shown in Figure 22.4, and attach this id to the projection of the tuple in each fragment. If we think of the original relation as containing an additional tuple-id field that is a key, this field is added to each vertical fragment. Such a decomposition is guaranteed to be lossless-join.”

As described by Elmasri and Navathe, a set of vertical partitions whose projection lists \(L_1, L_2, ... , L_n\) include all the attributes in \(R\) but share only the primary key attribute of R is called a complete vertical fragmentation of \(R\). Therefore, in this case, the projection lists satisfy the following conditions:

1. \(L_1 \cup L_2 \cup ... \cup L_n = ATTRS(R)\);
2. \(L_i \cap L_j = PK(R)\), for any \(i \neq j\),

where ATTRS(R) is the set of all attributes of R and PK(R) is the primary key of R;

And to reconstruct the relation R from a complete vertical fragmentation, we apply the OUTER UNION operation to the vertical fragments. Furthermore, for the \(R_1, R_2, ... R_n\) vertical fragments of \(R\), we have that \(R_1 \cap R_2 \cap ... \cap R_n = A\), where \(A\) is a unique key attribute of \(R\).

Hybrid Partitioning

A hybrid partitioning is the combination of horizontal partitioning and vertical partitioning, also called mixed partitioning. In this kind of partitioning, a fragment of a relation R can be specified by a SELECT-PROJECT combination of operations \(\pi_L(\sigma_C(R))\), and the original relation \(R\) can be reconstructed by applying UNION and OUTER UNION (or OUTER JOIN) operations in the appropriate order.

In the Employee table example, if we partition by Department Number (Dno) and Social Security Number (SSN), there are four resulting partitions:

2. Allocation

Allocation assigns a fragment to a particular node. The choice of site and degree of replication will be driven by performance and availability requirements. Some partitions may be replicated across all nodes of the system, while others remain local to a particular site, for example.

3. Replication

Replication allows the storage of several copies of data to achieve data locality (i.e., keep the data closer to where it is most needed), availability (the probability that a system is continuously available during a time interval), reliability (the probability that a system is running at a certain point in time) and faster query execution by using local copies.

The logical units of replication will vary depending on the requirements of the application, performance requirements, patterns of access, types and frequencies of transactions, and availability requirements. Basically, there are two extremes of replication: no replication at all – that is, each relation or fragment is stored in a single node – on one side and whole database replication on all nodes on the other side (called a fully replicated database). In between, we have a spectrum of partial replications of tables and table partitions. For example, H-Store/VoltDB supports both partitioned and replicated tables (that is, the whole table is replicated among all the nodes). The latter is used for small tables that are read-only or not frequently updated like a COUNTRY table, for example, while other tables are horizontally partitioned among the nodes.

A thorough treatment of replication is beyond the scope of this blog post, but it’s strongly recommended that interested readers check Özsu and Valduriez’s[2], Kleppmann and Riccomini’s[4], or Petrov’s[5] chapters devoted to this subject.

So what is sharding (in the academic perspective), after all?

All the authors cited so far address sharding in their works, but with slightly different nuances among them. For Özsu and Valduriez, Elmasri and Navathe, Ramakrishnan and Gehrke, and Silberschatz et al, sharding is a synonym for horizontal partitioning, and they acknowledge that the term is especially widespread in the context of NoSQL databases, Big Data, and Cloud Computing systems.

But Silberschatz et al also argument that in sharding architectures each node can have a traditional centralized, maybe independent, database instance (like standalone full MySQL DB instances, for example) and the queries would be routed by a middleware. In this architectural model, the sharding query requests can be executed by the database, or a middleware, or even application code. Each shard is an independent and standalone database that replicates all the database schema, but has only \(\frac{1}{N}\) of the data, in a cluster of size N.

Key Takeaways

Based on what we have seen so far, a more concise definition of sharding could be:

Sharding is horizontal partitioning of data distributed across different nodes.

And we may establish the following relation:

Every sharding is a partitioning, but not every partitioning is a sharding.

This derives directly from the fact that there are partitioning on a single node, for example, while sharding usually involves horizontal partitioning + allocation among various nodes. Therefore, a key takeaway relationship among all of the main concepts exposed so far could be:

Or as a cool cheat sheet:

References

1. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.
2. Özsu, M. T., & Valduriez, P. (2020). Principles of Distributed Database Systems (4th ed.). Springer.
3. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill.
4. Kleppmann, M., & Riccomini, C. (2026). Designing Data-Intensive Applications (2nd ed.). O’Reilly.
5. Petrov, A. (2019). Database Internals (1st ed.). O’Reilly.
6. Georgiev, N. (2008). A Web-Based Environment For Learning Normalization of Relational Database Schemata (Master’s thesis).

Early this week, during a book club session, I found myself stumbling through the nuances of clustered indexes, index-organized tables and covering indexes, only to be corrected by fellow readers that were going strictly by Kleppmann and Riccomini’s Designing Data-Intensive Applications (2nd Edition, 2026). Driven by my confusion, I hit the books and the web to untangle it all.

While I’d learned it first from Silberschatz, Korth & Sudarshan’s Database System Concepts (currently on 7th Edition, 2021), and a couple of lesser-known books, Kleppmann and Riccomini’s definition matches something else entirely. And it turns out their usage is the one that matches the industry’s actual database engine implementations! Therefore, neither of us were way off during the book discussion or inventing anything, for that matter; we were just each drinking from different wells. 🥲

This post is the writeup I wish I’d had going into that conversation. ;-)

The claim that started it

The definition I knew, in Silberschatz, Korth, and Sudarshan’s own words:

“… a clustering index is an index whose search key also defines the sequential order of the file. Clustering indices are also called primary indices; the term primary index may appear to denote an index on a primary key, but such indices can in fact be built on any search key. The search key of a clustering index is often the primary key, although that is not necessarily so. Indices whose search key specifies an order different from the sequential order of the file are called non clustering indices, or secondary indices. The terms “clustered” and “nonclustered” are often used in place of “clustering” and “non clustering.”

In other words, they describe a clustering index as one where the heap file itself is ordered according to the index search key.

But if we check the literature a bit further, Elmasri and Navathe’s Fundamentals of Database Systems (7th ed, 2016) has an even more specific definition of Clustering Indexes:

“If file records are physically ordered on a nonkey field — which does not have a distinct value for each record — that field is called the clustering field and the data file is called a clustered file. We can create a different type of index, called a clustering index, to speed up retrieval of all the records that have the same value for the clustering field. This differs from a primary index, which requires that the ordering field of the data file have a distinct value for each record. A clustering index is also an ordered file with two fields; the first field is of the same type as the clustering field of the data file, and the second field is a disk block pointer. There is one entry in the clustering index for each distinct value of the clustering field, and it contains the value and a pointer to the first block in the data file that has a record with that value for its clustering field.

(…)

A clustering index is another example of a nondense (E.N., sparse) index because it has an entry for every distinct value of the indexing field, which is a nonkey by definition and hence has duplicate values rather than a unique value for every record in the file.”

There’s a subtle distinction worth flagging here. In Elmasri and Navathe terminology, if the physical ordering field is the primary key, they normally call the associated index a primary index, not a clustering index.

Independently, Oracle has used the term Index-Organized Table (IOT) since at least Oracle8, though the underlying idea predates the name. In Oracle’s own docs, an IOT is a table with no separate heap file, that is, the data lives directly inside a B-tree, keyed by (typically) the primary key.

DDIA collapses both of these into a single definition:

“If the actual data (row, document, vertex) is stored directly within the index structure, it is called a clustered index. For example, in MySQL’s InnoDB storage engine, the primary key of a table is always a clustered index, and in SQL Server, you can specify one clustered index per table [43].”¹

But that’s not an error on their part! It’s the terminology MySQL’s InnoDB, SQL Server and TiDB, among others, actually use in their own documentation. The “clustered index” in their world is what Oracle calls an index-organized table. Same structure, different products/companies, different words.

Markus Winand’s SQL Performance Explained (2nd edition, 2025) reconciles IOT and clustered index definitions, as quoted below:

“Some databases can indeed use an index as primary table store. The Oracle database calls this concept index-organized tables (IOT), other databases use the term clustered index. In this section, both terms are used to either put the emphasis on the table or the index characteristics as needed. An index-organized table is thus a B-tree index without a heap table. This results in two benefits: (1) it saves the space for the heap structure; (2) every access on a clustered index is automatically an index-only scan. Both benefits sound promising but are hardly achievable in practice.”

Three structures, one collision

Before getting to the confusing part, here’s the structure everyone agrees on and the baseline the other two get compared against.

1. The baseline: heap file + ordinary secondary index

Rows sit in an unordered heap and a B+-Tree index points into it.

2. “Clustering index”: the academic vernacular (Silberschatz’s/Navathe’s)

The heap file is still there, but it’s been physically sorted to match the index key. Because order matches, the index doesn’t even need an entry for every row, one entry per disk block is enough (i.e., it can be a sparse index).

The important detail: this is a maintained property, not a structural guarantee. New inserts can land out of order until the next reorganize. OPTIMIZE TABLE in MySQL’s MyISAM engine, or CLUSTER in PostgreSQL are both real-world instances of this exact concept.

Db2 goes a step further than MySQL and PostgreSQL: it names this concept directly. Its own documentation describes a clustering index as one that determines how rows are physically ordered in a table space; a genuinely separate object from the table, exactly like Silberschatz’s model. Db2 even tracks a cluster ratio to measure how well-sorted the heap currently is, and recommends a REORG when it drifts.

One caveat: Db2’s clustering index is still a dense (B-tree) index, with one entry per row. Silberschatz’s definition allows the index itself to go sparse once ordering is guaranteed, but Db2 doesn’t take that shortcut. So it’s a real match on the heap-file question, just not on the sparse-index detail.

3. “Clustered index” / index-organized table: the engineering vernacular (InnoDB, SQL Server, Oracle IOT, TiDB)

No heap file exists. The B-tree’s leaf nodes directly hold the row data.

Here the sort order isn’t something you maintain. It’s structurally impossible to violate, because there’s nothing to fall out of sync. The row is the leaf.

One more consequence follows directly from structure 3:

4. The two-hop cost of secondary indexes on a clustered index

Once there’s no heap to point into, a secondary index (say, on email) can’t store a physical rowid. It stores the clustering key instead, then does a second lookup into the clustered B-tree index to fetch the row.

This two-hop pattern is exactly what Kleppmann and Riccomini are describing when they discuss the cost of secondary indexes on clustered-index tables in DDIA book!

By the way, Winand lays out exactly why this hurts once you add a second index on top of a clustered one. As the rows inside an index-organized table can move at any time to preserve B-tree order, a secondary index can’t store a physical pointer (rowid) to them, so it has to store the clustering key (often the primary key) instead and use that to look the row up.

In practice, this means every lookup through a secondary index costs two searches instead of one: an INDEX RANGE SCAN² on the secondary index, followed by an INDEX UNIQUE SCAN³ into the clustered index for each match. By the way, I am borrowing Oracle’s EXPLAIN PLAN vocabulary here purely as an illustration of the two-hop pattern; InnoDB and SQL Server surface the same cost under their own plan-operation names. As Winand puts it, “accessing an index-organized table via a secondary index is very inefficient.”

The fix is the same one used for heap tables: an index-only scan, though here it’s better described as a “secondary-index-only scan”; and the payoff is even bigger, since it eliminates an entire INDEX UNIQUE SCAN per row rather than a single table access.

Why the definitions collided

• Oracle calls this structure an index-organized table and reserves cluster for something unrelated (i.e., multiple tables sharing storage blocks by a cluster key);
• MySQL/InnoDB and Microsoft SQL Server call the same structure a clustered index;
• Classical database texts like Silberschatz et al’s and Navathe et al’s are describing a different axis of classification: does index order match file order? Not whether the heap exists at all…
• IBM Db2 is the outlier that actually lines up with the classical texts: its clustering index is a genuinely separate object from the table, and Db2 tracks how well the two stay in sync, that is, the same axis Silberschatz is describing, not the IOT axis Oracle/MySQL/SQL Server are on.

Two structures, several vocabularies, one underlying set of concepts, with Db2 being the rare case where a vendor’s terminology and the classical textbook terminology actually agree. But none of the sources is “wrong” in isolation; the confusion only shows up when you read across them, or cross-references them, which is exactly what happens in a book club drawing on multiple references.

Bonus round: covering index (no controversy here!)

Not every indexing term is contested. While looking into this, I also revisited covering index, as defined in Markus Winand’s SQL Performance Explained (2025). Unlike the clustered/clustering mess, this one is consistent everywhere: SQL Server docs, PostgreSQL literature, Couchbase docs, and Winand’s book all agree:

A covering index contains every column a query needs —SELECT-list columns as well asWHEREandJOIN columns —, so the database engine never has to visit the underlying table at all.

Or specifically quoting Winand’s book:

“If an index prevents a table access it is also called a covering index.The term is misleading, however, because it sounds like an index property. The phrase index-only scan correctly suggests that it is an execution plan operation.”

The nice part: this concept is orthogonal to the clustering debate above. It applies whether you’re skipping a hop to a heap file (Silberschatz et al’s clustering index) or skipping a hop into a clustered B-tree (DDIA’s clustered index).

By the way, a YugaByte’s blog post goes further by citing other covering indexes’ diverse names:

“The solution is simple and has many names: “covering index”, “include index”, “projection index”, “fat index” and even “Tapio index” from the name of the author of “Interscience Relational Database Index Design and the Optimizers” (Tapio Lahdenmäki) who explained this in detail.”

But, all in all, they’re all aliases/nicknames for the same mechanism, not competing definitions. Phew! 😅

A key takeaway

If you’re reading multiple database books then assume “clustered/clustering index” means different things depending on which book is in your hand, until proven otherwise. When in doubt, ask yourself: is there a separate heap file here, or not? That question cuts through the vocabulary every time.

Cheers!
Edward

August, 28th, 2026