top of page

Database: Types of Database and Factors to consider when Choosing a database:

Updated: Mar 27

What is a Database?

A database is an organized collection of data so that can be easily accessed and managed. You can organize data into tables, rows, columns, and index it to make it easier to find relevant information. The main purpose of the database is to operate a large amount of information by storing, retrieving, and managing data. There are many dynamic websites on the World Wide Web nowadays which are handled through databases. For example, a model that checks the availability of rooms in a hotel. It is an example of a dynamic website that uses a database.

Different types of Database

1. Relational Database

Relational databases are the most commonly used type of database. Data is organised in tables which, unsurprisingly, can have relations defined with each other using foreign keys. SQL allows you to query these tables and join them together, allowing you to efficiently retrieve data in a format that suits your requirement. Tables are structured using columns and rows, where columns define the data attributes and the rows define a record within the table.


  1. The tables with the specific data have relation among them that’s why the required data is taken from the previous tables which prevents the data redundancy.

  2. The data access is privileged which means that the database administrator has the authority of giving access of data to some particular users which makes the data secure.

  3. This type of database uses tables which is better and easy to create and use.


  1. As compared to other databases this database has a slow extraction of results thus making it a slower database.

  2. The database uses tables having rows and columns which consumes a lot of physical memory which becomes a disadvantage of the database.

2. Graph Database

Graph databases are defined using nodes — which define the data stored — and edges, which store the relationships between nodes. This storage of relationships means that joining these sets of data is extremely quick, in contrast, a relational database would compute these at query time, slowing down the entire process.

Types of Graph Database

Many multi-model databases support graph modeling. However, there are numerous graph native databases available as well.

  1. JanusGraph: JanusGraph is a distributed, open-source and scalable graph database system with a wide range of integration options catered to big data analytics.

  2. Neo4j: Neo4j (Network Exploration and Optimization 4Java) is a graph database written in Java with native graph storage and processing.

  3. DGraph: DGraph (Distributed graph) is an open-source distributed graph database system designed with scalability in mind.

  4. DataStax Enterprise Graph: The DataStax Enterprise Graph is a distributed graph database based on Cassandra and optimized for enterprises


  1. The structures are agile and flexible.

  2. The representation of relationships between entities is explicit.

  3. Queries output real-time results. The speed depends on the number of relationships.


  1. There is no standardized query language. The language depends on the platform used.

  2. Graphs are inappropriate for transactional-based systems.

  3. The user-base is small, making it hard to find support when running into a problem.

3. Document Database

Document databases typically store data as structured nested documents (think JSON/BSON, XML), meaning that they intuitively correspond to the objects in your code. These documents are stored in collections, and are analogous to a row and table in a relational database.

Below are some of the best Document Database:

1. Amazon Document DB

2. Mongo DB

3. Cosmos DB

4. Arango DB

5. Couchbase Server

6. Couch DB


  1. Schema-less. There are no restrictions in the format and structure of data storage. This is good for retaining existing data at massive volumes and different structural states, especially in a continuously transforming system.

  2. Faster creation and care. Minimal maintenance is required once you create the document, which can be as simple as adding your complex object once.

  3. No foreign keys. With the absence of this relationship dynamic, documents can be independent of one another.

  4. Open formats. A clean build process that uses XML, JSON and other derivatives to describe documents.

  5. Built-in versioning. As your documents grow in size they can also grow in complexity. Versioning decreases conflicts.


  1. Consistency-Check Limitations. In the book database use case example above, it would be possible to search for books from a non-existent author. You could search the book collection and find documents that are not connected to an author collection. Each listing may also duplicate author information for each book. These inconsistencies aren’t significant in some contexts, but at upper-tier standards of RDB consistency audits, they seriously hamper database performance.

  2. Atomicity weaknesses. Relational systems also let you modify data from one place without the need for JOINs. All new reading queries will inherit changes made to your data via a single command (such as updating or deleting a row). For document databases, a change involving two collections will require you to run two separate queries (per collection). This breaks atomicity requirements.

  3. Security. Nearly half of web applications today actively leak sensitive data. Owners of NoSQL databases, therefore, need to pay careful attention to web app vulnerabilities.

4. Key/Value Database

Key/value stores are the most conceptually simple of the databases; it is a non-relational database where values are stored against keys. These values can be as simple as a single piece of data, up to more complex objects, similar to documents. This sounds extremely similar to a document database, however in a key/value database, the information stored against the key is less transparent. This means that for a document database, you can query against non-primary keys, allowing for higher flexibility, whereas with a key/value database, you are typically limited to querying against a single primary key.


  1. Simple data format makes write and read operations fast

  2. Value can be anything, including JSON, flexible schemas


  1. Optimized only for data with single key and value. A parser is required to store multiple values.

  2. Not optimized for lookup. Lookup requires scanning the whole collection or creating separate index values

5. Wide Column Database

When querying big data to generate analytics and reports, it’s rare that you wish to query every column of every row and quite inefficient to do so. Even when reducing the number of columns selected, this still can result in large volumes of unnecessary data being parsed! Wide column/column family databases, circumvent this issue by partitioning data in columns, and when it comes to querying, only the columns required are retrieved. The result of this is a sparse matrix of partitioned columns, containing a single data type (wide column), or column families which store a row, which in turn has nested columns and values within itself.


  1. MASSIVE scalability. Petabyte-scale data. Even beyond petabytes.

  2. consistent, performant performance on HEAVY write loads


  1. inefficient updates

  2. inefficient joins / aggregations

Factors to consider when choosing a database

Choosing a database is a critical decision for any organization. The right database can help you store and manage your data efficiently, provide scalability and reliability, and support the applications that drive your business. There are several factors to consider when choosing a database, including:

  1. Data type and volume: The type and volume of data you need to store and manage can impact your database selection. For example, if you need to store unstructured data such as documents, images, or videos, you might consider a NoSQL database. On the other hand, if you need to store structured data like financial transactions or inventory records, a relational database might be a better choice.

  2. Scalability: As your business grows, so will your data needs. You want a database that can scale with your organization's needs. Consider the size of your data, the number of concurrent users, and the expected growth rate when choosing a database. You might consider a distributed database like Apache Cassandra for its ability to scale horizontally across multiple nodes.

  3. Performance: Database performance can significantly impact application performance. Factors like latency, throughput, and response time can impact the user experience. Consider the speed and reliability of the database when selecting one. You might consider a database with in-memory capabilities or optimized for read-heavy workloads.

  4. Cost: The cost of a database is an important consideration. This includes the licensing fees, hardware requirements, and maintenance costs. Some databases are free and open-source, while others require a subscription or licensing fees. Consider the long-term costs and ROI when selecting a database.

  5. Availability and reliability: Your database must be available and reliable, especially for mission-critical applications. Consider the database's architecture, features like backup and recovery, and disaster recovery options. A database with built-in high-availability features like automatic failover can ensure uptime and business continuity.

  6. Security: Your database should be secure, protecting sensitive data from unauthorized access or data breaches. Consider the database's security features like encryption, access controls, and auditing. You might consider a database with compliance certifications like PCI DSS or HIPAA.

  7. Ecosystem and support: Consider the ecosystem around the database, including third-party tools and integrations. A database with a robust ecosystem can provide additional functionality and flexibility. Also, consider the level of support provided by the vendor or community. This includes documentation, training, and support channels.

By taking the time to assess these factors, you can choose a database that meets your organization's needs today and in the future.

bottom of page