systemdesign/database

Introduction

a database is designed to solve a particular problem really well.
Each kind of database picks a segment with a slight overlap.

A database is typically designed to solve a particular class of problems really well. Each kind of database—relational or non-relational—focuses on a specific segment of use cases, often with some overlap.

Non-relational databases are often chosen for scenarios where relational databases struggle to scale. These systems usually:

  • Avoid strict relationships and constraints
  • Are designed with scalability and sharding in mind
  • Emphasize flexibility over consistency in some cases

However, it’s possible to scale relational databases effectively if we relax certain constraints. To achieve this, we can:

  • Avoid foreign key checks – Removing these can reduce coupling between tables and allow more parallelism.
  • Avoid cross-shard transactions – They are expensive and hard to coordinate at scale.
  • Implement manual sharding – Partition the data at the application level, directing queries to the correct shard.

By giving up some of the traditional features of relational databases, we can gain performance and scalability, similar to what non-relational systems offer—while still benefiting from mature SQL ecosystems and tools.

Choose database system ?

  1. understand what data you are storing ?
  2. understand how much of data you will be storing.
  3. understand how you will be accessing the data
  4. what kind of queries you will be firing
  5. Any special feature you expect