Most of the traditional relational databases are considered OLTP. The transactional database is the oldest and most popular method of storing and handling application data. Some examples of relational OLTP databases are Oracle, Microsoft SQL Server, MySQL, PostgreSQL, Amazon RDS, as well as others. The data access pattern for OLTP involves fetching a small dataset by looking up their ID. A database transaction means that either all related updates of the database table completed, or none of them did.

The relational model allows the processing of complex business transactions in an application, such as banking, trading, and e-commerce. It will enable you to aggregate data and create complex queries using multiple joins across tables. While optimizing your relational database, you need to consider including the following optimizations:

• Database server that includes computing, memory, storage, and network
• Operating system-level settings, such as a RAID configuration of the storage volume, volume management, and block size
• Database engine configuration and partition as required
• Database-related options, such as schema, index, and view

Scaling can be tricky for the relational database as it can scale vertically and hit the upper limit of system capacity. For horizontal scaling, you have to read the replica for read scaling and partition for write scaling. In the previous chapter, you learned how to scale a relational database in the section titled Database handling in the application architecture.

OLTP databases are suitable for large and complex transactional applications; however, they don't scale well where a massive amount of data needs to aggregate and be queried. Also, with the internet boom, there is a lot of unstructured data that is coming from everywhere, and relational databases are not able to handle unstructured data efficiently out of the box. In this case, the NoSQL database comes to the rescue. Let's learn more about how to handle a nonrelational database.