Traditional database systems were a centralised powerful database server that housed all operations pertaining to the database.

There are countless reasons that this is unsustainable when larger databases are employed, specifically for globally distributed companies and popular applications as already known today.

A single database server may suit many database’s requirements, but at some point, there may be a need to scale up to support higher demand or for global capacity requirements of sorts (Shalom, 2017).

Scaling a database can be a very challenging task requiring many complex technical adjustments and operations to take place.


There are currently two main ways to scale, vertically and horizontally.

Vertically is simply adding more resources to a single database server to provide more power and space, but there are always limits to how much you can upgrade a single machine.

The alternative is horizontal scaling, which is when you add many machines connected together on a network to shard pieces of the database among themselves.

Horizontal scaling is becoming increasingly more popular and allows for an indefinite amount of computers to form a single distributed database system in any combination of locations.

The true definition of a distributed database is one that can be stored on different systems such as personal computers, servers, mainframes, start-phones or any other network connected devices in any location around the globe.


  • Fault tolerance as a single machine?s failure does not mean system-wide downtime.
  • Latency can be reduced as copies of the database can be replicated closer to the source of usage or retrieval location.
  • Adding machines as and when needed for constant growth (Hanks, 2017).
  • Improved availability as the fault of a single entity on the network does not affect the entire cluster.
  • Cost savings as smaller, cheaper hardware can be used to form a distributed system instead of single higher powered more costly machines.


  • Synchronizing needs to be done perfectly to maintain a correct state of data throughout the system.
  • There are many more machines to patch and update leading to potential security breaches.
  • Static SQL cannot be used (, 2013).
  • Deadlocks can be difficult to resolve over a distributed setup (Kandasamy, 2014).
  • The complexity with many systems distributed across the globe adds additional cost with setup, maintenance, upgrades and fault resolution.
  • Lack of standards (Thakur, n.d.).
  • Data design is more complex in order to both shard and replicate data across multiple availability zones.

Distributed database systems are definitely the future and we need to embrace them.

However, given that there are still no clearly defined standards outlined for this or that this field is still very much being developed and tried out by both companies small and large; it may be a long time until there is a clear cut way for implementing a standardised distributed database system.

My own foray

In my endeavours to wholly understand distributed systems, I ended up creating a truly autonomous distributed database system, which you can read about here or just dive right into the code over here.


Shalom, N. (2017) Difference between scaling horizontally and vertically for databases [Online], Available from:

Hanks, G. (2017) The Advantages of Using Distributed Databases for the Banking Industry [Online], Available from: (2013) Advantages and disadvantages of distributed database [Online], Available from:

Kandasamy, S. (2014) Advantages and Disadvantages of Distributed Databases [Online], Available from:

Thakur, D. (n.d.) What are the Advantages and Disadvantages of Distributed Database Management System? [Online, Available from: