Wikiwand explains what sharding is and enumerates examples of key sharding providers including Altibase

Shard (database architecture)

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article’s tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia’s guide to writing better articles for suggestions. (May 2010) (Learn how and when to remove this template message) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (May 2010) (Learn how and when to remove this template message) (Learn how and when to remove this template message)



Database architecture



Disadvantages include:

Main section: Disadvantages


In practice, sharding is complex. Although it has been done for a long time by hand-coding (especially where rows have an obvious grouping, as per the example above), this is often inflexible. There is a desire to support sharding automatically, both in terms of adding code support for it, and for identifying candidates to be sharded separately. Consistent hashing is a technique used in sharding to spread large loads across multiple smaller services and servers.[3]


Shards compared to horizontal partitioning

Horizontal partitioning splits one or more tables by row, usually within a single instance of a schema and a database server. It may offer an advantage by reducing index size (and thus search effort) provided that there is some obvious, robust, implicit way to identify in which partition a particular row will be found, without first needing to search the index, e.g., the classic example of the ‘CustomersEast‘ and ‘CustomersWest‘ tables, where their zip code already indicates where they will be found.






Notable implementations

  • Altibase: provides combined(client-side and server-side) sharding architecture transparent to client applications.
  • Apache HBase: HBase provides automatic sharding.[4]
  • Azure SQL Database Elastic Database tools: enables the data-tier of an application to scale out and in via industry-standard sharding practices[5]
  • Couchbase: provides automatic transparent sharding as well as extreme performance.
  • CUBRID: allows sharding from version 9.0
  • Elasticsearch: enterprise search server provides sharding capabilities.[6]
  • Hibernate Shards: provides for shards, although there has been little activity since 2007.[8][9]
  • Kdb+: allows sharding from version 2.0
  • MonetDB: the open-source column-store MonetDB allows read-only sharding as its July 2015 release.[12]
  • MongoDB: allows sharding from version 1.6
  • MySQL Fabric (part of MySQL utilities) includes sharding capability.[14]
  • Oracle Database Sharding: introduced as new feature in Oracle RDBMS12c Release 2 and in one liner: Sharding is a data tier architecture in which data is horizontally partitioned across independent databases.[15]
  • Oracle NoSQL Database: has automatic sharding and elastic, online expansion of the cluster (adding more shards).
  • OrientDB: allows sharding from version 1.7
  • Solr enterprise search server: provides sharding capabilities.[16]
  • Spanner: Google’s global-scale distributed database, shards data across multiple Paxos state machines to scale to “millions of machines across hundreds of datacenters and trillions of database rows”.[17]
  • SQLAlchemy ORM: a data-mapper for the Python programming language that provides sharding capabilities.[18]
  • The DWH of Teradata: a massive parallel database



  • Increased complexity of SQL – Increased bugs because the developers have to write more complicated SQL to handle sharding logic.
  • Sharding introduces complexity – The sharding software that partitions, balances, coordinates, and ensures integrity can fail.
  • Single point of failure – Corruption of one shard due to network/hardware/systems problems causes failure of the entire table.
  • Failover servers more complex – Failover servers must themselves have copies of the fleets of database shards.
  • Backups more complex – Database backups of the individual shards must be coordinated with the backups of the other shards.
  • Operational complexity added – Adding/removing indexes, adding/deleting columns, modifying the schema becomes much more difficult.

These historical complications of do-it-yourself sharding were addressed by independent software vendors who provided automatic sharding.


The word “shard” in a database context may have been introduced by the CCA‘s “System for Highly Available Replicated Data”.[19] There has been speculation[20] that the term might be derived from the 1997 MMORPG Ultima Online and Richard Garriott, creator of Ultima Online claims as much,[21] but the SHARD database system predates this by at least nine years.

However, the SHARD system appears[22] to have used its redundant hardware only for replication and not for horizontal partitioning. Present-day use of the term “shard” may or may not derive from the CCA system, but in any case it refers to a different use of redundant hardware in database systems.

What is sharding? @Alexander Lielacher

What Is Sharding?


What Is Sharding?

Sharding is a concept in database design, and as implied by its name, sharding involves creating smaller parts from a larger one. In the context of databases, sharding results in the creation of smaller partitions in the ledger. These partitions are thus referred to as shards.

It is important to note that in sharding, the partitioning is done horizontally as opposed to vertically. A shard may contain data that is in all the other shards; however, these partitions are designed to include data that is accessible only through it, which means that the data in each shard is unique to it. To access the data and use it, one must queue the specific shard that contains said data.

Sharding is employed in database architecture because it can improve the performance of a database or search engine. The design tool does this because it reduces the index size of a ledger. As a result, the ledger can provide search results quicker. Additionally, because different shards can be stored on different servers, the tool can be beneficial for large corporations with large data sets that they need to store separately such as multinational corporations operating in different countries.

Sharding in Distributed Ledgers

Sharding has grown in popularity within the cryptocurrency community as a result of widespread concerns over blockchain scalability issues. For instance, the Bitcoin Network processes about seven transactions per second, and Ethereum is only slightly faster, handling around 15 operations per second. These are both paltry compared to large payment processors like Visa and Mastercard.

While the bitcoin community has dealt with its scaling issues in various ways, the Ethereum project has outlined a more streamlined approach to solving its scalability concerns. Ethereum’s approach involves switching to a Proof of Stake (PoS) algorithm, which will work in tandem with a sharded database design.

How Would Sharding Work on Ethereum?

During his keynote speech at an event held at the School of Business of the Singapore University of Social Sciences, Ethereum’s cocreator Vitalik Buterin attempted to explain the concept of sharding the Ethereum ledger in a straightforward manner. In his talk entitled “The Road Ahead,” he stated:

“Imagine that Ethereum has been split into thousands of islands. Each island can do its own thing. Each of the islands has its own unique features and everyone belonging on that island, i.e., the accounts, can interact with each other and they can freely indulge in all its features. If they want to contact with other islands, they will have to use some sort of protocol.”

Currently, on the Ethereum network, as well as other blockchains, each node stores the global state. The globals state refers to the account balances, contract code and storage and all additional relevant information. Additionally, all nodes process all transactions. While this provides for a very secure ledger, it dramatically limits to what extent the network can scale because, within this design, a blockchain is only as good as a single node on its network.

In other words, the speed of a blockchain is defined by how quick a single node is as all nodes must perform the same transaction over and over.