What Is a Database (in software)?

You know how you need space to store things? That’s what a database is, a digital place where we put information so that it can be stored securely, efficiently, and accessed quickly. Databases can be stored online and offline, we’ll discuss they work online.

A database is an important software piece used to build apps, websites, web software, and digital platforms.

Imagine a large number of tables with information stored in them; a database is essentially a collection (large or small) of all these “tables.”

‍

‍

What Can You Store in a Database?

Most mobile, computer, or online applications use databases to store, manage, and recall data so they can function properly. For example, if you build a Digital Wallet app, here’s what your app’s database could have:

User data: images, bank account details, passwords, etc
Application data: Metadata, App Audit Record Data, CRON Job Trigger Data, etc

‍

‍

Relational Databases

A relational database stores and manages data points that are related to each other. Think of them like an organized collection of tables where each row of data can be connected to another similar row.

Relational databases follow a predefined structure (or schema) to allocate space, identity, and relations to data points. The whole table is affected by adding even just one column.

‍

‍

‍

A way to manage relational databases is through Relational Database Management Systems aka RDBMS.

‍

Popular use cases:

  • To track historic changes within your data
  • To store and manage large amounts of data
  • For online transactions
  • To create tightly structured databases

‍

Example of a popular use case

Thanks to the ACID property (explained later in this blog) of Relational Databases, an online money transaction either happens completely, or doesn't happen at all. Which means, when you transfer $10 from one account to another, two database queries take place, one from the sender, and one from the recipient. If either of the queries fail, the entire transaction fails, ensuring the $10 aren’t lost.

‍

Popular relational DBs:

  • PostgreSQL
  • MySQL
  • SQL Server

‍

Relational Database Schema

The schema in a relational database dictates how your database structure, and is defined by instructions supported by its respective system. Think of it like a skeleton or an outline of what your database will be built like. Your database schema can make or break the performance of the RDBMS you’re using, and if you’re building an application, make sure you design database schemas for efficiency.

‍

‍

ACID (Atomicity, Consistency, Isolation, Durability)

The ACID property of Relational Databases ensures that a transaction in a database either happens completely or doesn’t happen at all.

Most non relational databases don’t have full ACID-compliance.

‍

Atomicity

Atomicity ensures that each atomic transaction between databases is processed as a single unit, which either succeeds or fails.

‍

Consistency

Consistency means that at any given point in time the data present within the database is correct as per the rules and constraints of an RDBMS.

‍

Isolation

Isolation in Relational databases means that all transactions are unaware of each other, which allows a RDBMS to read and write into a table concurrently.  

‍

Durability

Durability is a mechanism that ensures whatever data point is recorded through a database transaction is committed, even in case of system failures, and is recorded in non-volatile memory.

‍

‍

Advantages of Relational Databases

  • You can represent complex data easily using relational tables
  • More data accuracy due to no duplication
  • Flexibility in data queries and scaling up
  • Easily accessible data
  • Data consistency and integrity

‍

Disadvantages of Relational Databases

  • Higher expenditure and infrastructure requirements to scale up
  • Slower queries and decreased speed due to increase in data size
  • Reliance on a database admin decreases deployment speed
  • Increased database complexity can lead to isolated databases
  • Rigidity due to dependence on fixed schemas
  • Not ideal for Agile software development

‍

‍

Scaling

Relational databases are easier to scale vertically. A table with a capacity for a million rows can store a million more by increasing the memory of that machine.

Vertical scaling means you can increase the storage of one machine to accommodate more data.

‍

‍

Non-Relational Database/NoSQL database

A Non-relational Database does not use a fixed schema for tables to store and manage information, they use a storage model that is designed for specific use cases. This property allows Non-Relational (or NoSQL) databases to be more flexible compared to a Relational Database.

Non-relational databases are also called NoSQL sometimes, with a key difference in how the two databases store and organize information.

Various non-relational databases are used to serve specific functions.

‍

Common use cases:

  • Inventory, asset, and content management
  • For large and diverse data types
  • To scale quickly and easily
  • Data for IoT (Internet of Things)
  • Fraud detection
  • Identity authentication
  • Data warehousing


Common non-relational databases:

  • MongoDB
  • CouchDB
  • CouchBase
  • Apache Cassandra
  • HBase
  • Redis
  • Riak
  • InfoGrid
  • Infinite Graph
  • OrientDB
  • FlockDB

‍

Non-relational database types

  • Key-value Database
  • Column Database
  • Document Database
  • Search (Graph) Database

‍

‍

Key-value Database

Key-value store is a form of Non-relational Databases that stores data as a collection of key-value pairs - where a key acts as a unique identifier for each value.

Due to their non-relational nature, Key-value databases are easy to scale in a horizontal manner.

‍

Examples of a Key-value Database

  • Redis
  • Apache Cassandra
  • Riak

Key-value databases are fast, and they provide quick data access because active applications can store data in the main memory during an ongoing user session.

‍

‍

Document Databases

Document-oriented databases are non-relational or NoSQL databases that use documents with data type descriptions and values to store and manage information. They offer more flexibility in structure and horizontal scalability.

Document-oriented databases let you use flexible schemas instead of a rigid table-based structure, which lets developers design data models for specific use cases.

Such databases use formats like JSON, BSON, and XML to create documents for data storage.

Document based databases are usually used when you are not sure of the schema or how the data may evolve over time. Document-oriented databases can support heavy reads and writes.

You can store product details for an item on your eCommerce website by creating data types like item name, item ID, price, availability, etc. And the value for each type of information is assigned to specific data types.

Here’s what a document database looks like:

‍

‍

Examples of a Document-oriented Database

  • MongoDB
  • CosmosDB
  • DynamoDB
  • MarkLogic
  • Azure Cosmos DB
  • Apache CouchDB

‍

Advantages (and reasons) to choose a document-oriented database:

  • Highly scalable
  • Easy horizontal scaling
  • Sharding
  • Dynamic data flexibility
  • Special querying operations aggregation
  • Easy to read and write

‍

Disadvantages of document-based databases

  • Lack of a strict scheme may result in null or empty values in your database
  • Lacks ACID property in most NoSQl databases to ensure transaction completion by default


‍

Columnar Database or Column Wide Stores

Columnar databases are NoSQL databases that are similar to relational databases, but are column-oriented. These types of databases offer more flexibility when compared to relational databases, and can be used for faster data querying when an application requires a high number of reads from a database.

Column-based databases use keyspaces to store and organise data, similar to how a relational database uses a schema. Inside a column database, each keyspace contains column families, each column family contains rows, and each row contains columns. Here’s how it looks.

‍

‍

Examples of columnar databases:

  • MariaDB
  • Apache Hbase
  • Apache Parquet
  • MonetDB
  • BigQuery
  • Amazon Redshift
  • Snowflake

‍

Common use cases:

  • Data warehousing
  • Query and analysis of large amounts of data

‍

Advantages (and reasons) to choose a document-oriented database:

  • Optimized for compression which can save disk space
  • Highly suitable for scalability
  • More flexible than relational databases
  • These are great for parallel processing

‍

Disadvantages of document-based databases:

  • Incompatible with Online Transaction Processing
  • Writing new data is time consuming for large databases


‍

Graph Databases

Graph databases are relationship-driven databases which store and manage information about the relationships between data. They store data within nodes and each node has edges that contain details about relationships of that node. As an advantage, Nodes can store limitless relational information.

A huge advantage of using graph databases is based on situations where relationships between data can have more value than the data itself.

‍

Examples of graph databases:

  • Neo4j
  • ArangoDB
  • Amazon Neptune
  • JanusGraph
  • OrientDB
  • Stardog
  • TigerGraph

‍

Common use cases:

  • To build eCommerce recommendation engines
  • Fraud detection
  • Master Data Management
  • Online Asset Management
  • To build contextual, relational search engines

‍

Advantages (and reasons) to choose a document-oriented database:

  • Highly flexible
  • Don’t rely on JOIN operations
  • Can scale up fast
  • Store unlimited relational & type data
  • Faster data access compared to relational databases

‍

Disadvantages of document-based databases:

  • Not optimum for high number of transactions
  • Low efficiency during full databases queries
  • Not optimum queries and analysis in data warehousing

‍

‍

The Verdict

Now that you’ve learned the common definitions, differences, advantages, disadvantages and use cases of different database types, do you feel ready to choose one? If you want help choosing the right database or tech stack for your project, get in touch with an expert from our team.

Choosing a database is critical for the performance of your applications. Factors like data type, industry use case, infrastructure, scale, and user expectations will help you pick one or a combination of databases that will work best for you.


Ask us more about our database capabilities.

‍