How to select a database for your next project!

Databases are like a tool-set. Choose the wrong one that will cost time and money both from your project.

It is important to choose the right one for the right project. Depends on project requirements and data type, the database always should be chosen first.

This article can be the ultimate roadmap for your next quest for DB.

Key-Value

Key-value databases are simple and easy to understand. As the name, this database contains keys and values like javascript object or python dictionary. Every key should be unique and points to some values.

key-value DB

Example:

1. Redis. (https://redis.io/)
2. Mem-Cached. (https://memcached.org/)
3. ETCD. (https://etcd.io/)

In the case of Redis and Mem-cached all the data held in memory, ths=is make the DB extremely fast but the amount of data will be limited.

Best For:

A key-value store is best in fast and small usage cases, especially your app's runtime data.

1. Caching
2. Pub/Sub
3. LeaderBoards
4. Message queues

Most of the time key-value DB use as a layer top on other DB.

Wide Column

It is like key-value DB with an extra dimension, like, each key point to one or more column families with a set of ordered rows. This makes it possible to holds related data together but unlike relational DB there is no schema that means it can hold unstructured data.

Wide column DB

Example:

1. H-Base. (https://hbase.apache.org/)
2. Cassandra. (https://cassandra.apache.org/)
3. Azure Table. (https://azure.microsoft.com/en-us/services/storage/tables/)

Best for:

Wide column DB de-centralize and can scale horizontally.

1. Time-series data.
2. Historical records
3. High-write, low-read data.

Document DB

In this DB, there are documents, each document contains key-value pairs. They are unstructured and don't require a schema. Documents are group together in collections. Collections can be indexed and organized in a logical hierarchy.

Document DB

Example

1. MongoDB. (https://www.mongodb.com/)
2. FireStore. (https://firebase.google.com/docs/firestore)
3. CouchDB. (https://couchdb.apache.org/)

Document databases are a general-purpose database. Documents database read operation is faster than update or write. This is easy to use and developer-friendly.

Best for:

1. Most mobile apps
2. Games
3. IoT
4. Content management.

Don't use it for a graph or highly connected data.

Relational DB

They are here from the dawn of the database. Old but stable. Its structures as a table, which consists of rows and columns. Table connect with each other via foreign-key(FK). The main problem with this DB is the schema. This means if DB not architect properly it can be a mess on the latter path.

RDMBS

Example:

1. MySQL (https://www.mysql.com/)
2. PostgreSQL (https://www.postgresql.org/)
3. MariaDB (https://mariadb.org/)

Usually, databases are ACID(atomicity, consistency, isolation, durability) compliance

Best for

Almost all applications. 90% of all applications available today are using one or another type of relational databases.

Don't use it for unstructured data and be cautious about the architecture step.

Graph

In this type of database, data represented a node and connection between them as the edge. It has the upper-hand when it comes to many-to-many relations in data. And much more and flexible modern in query approach.

Graph DB

Example:

1. AllegroGraph (https://allegrograph.com/)
2. Neo4j (https://neo4j.com/)

Graph databases are the best alternative for SQL when there is lots of join and relation within data.

Best for:

1. Graphs.
2. Knowledge graph.
3. Recommendation system.

Search

In this category, databases should be able to fo a Fulltext search in a very short amount of time. Most of the DB in this category based on the:

Apache-Lucene Project (https://lucene.apache.org/)

Example:

1. Solr (https://lucene.apache.org/solr/)
2. ElasticSearch (https://www.elastic.co/)
3. Algolia (https://www.algolia.com/)

From the developer perspective, they work very similarly to a document-oriented database. It starts with an index and data related to that index.

In the back, the database analyzes all the data and create a searchable index to deliver fast result.

Best for:

1. Search Engine
2. Type Head

Multi-Model

Most exciting out of them all. Think as a front-end developer, you need only the data you want which is not possible in most of the database and query system. They will return you with lots of another, which you need to map in the later and manipulate into a correct shape. Ultimately all of this operation will create performance issues.

graphql vs rest

The best tool for this is the query language called GraphQL(https://graphql.org/)

In these DB models, you can query only the things you need for your application.

Example:

1. FaunaDB (https://fauna.com/)

Best for almost everything. The important bit is the query language itself, not the DB.

Which database you will select for your next project!