Applications have to make up for the shortcomings of data models

Applications choose to go with either a Relational model (the SQL way) or a Document model (the NoSQL way). Relationships decide the best data model fit. Databases are increasingly merging the relational and document model worlds. There may be databases in the future that are a hybrid of the relational and document models. But until then, we will need to address the shortcomings of each data model within the application.

Document data models offer a few compelling advantages to modern applications that have made them popular in the last decade. Document data models have excellent data locality, which also means Document data models are closer to data structures in applications. Data structures can be schemaless, with optional support for schemas (as in Elasticsearch and Mongo).

A primary weakness with document databases is handling relationships. Most document databases have no support for joins. One-to-many relationships can easily fold under the parent, but document databases lack support for many-to-one and many-to-many connections.

Applications can connect two documents only by performing multiple queries or maintaining a denormalized duplicate of the document. Maintaining the denormalized form requires additional work. Patterns like data triggers or domain events can populate and keep the denormalized version up-to-date. But these workarounds often lead to performance issues and increased application complexity.

Document size is also a cause for concern because updates rewrite a document in its entirety. For this reason, Document sizes should remain fairly small. Data that would bloat the document, but is needed only in a few use cases, is better kept separate.

Relational databases have already ruled the data storage space over the last three decades. They are perfect for joins and modeling relationships. Many modern relational databases (like PostgreSQL and MySQL) support storing schemaless data in JSON and XML formats.

A primary issue with relational databases is the awkward translation between object data structures and flat relational models. The onus falls on applications to bridge the gap, all the while maintaining readable code.

ORMs map the OOP world to a relational data model. They can hide complexities that may have to be otherwise dealt with by the application directly.

Using ORMs does not eliminate the application's need for data in an object-oriented format. For every query, applications may have to collect all necessary data from the database, joining tables where necessary, and package it into object form.

Relational databases are also clearly schema heavy. The application is responsible for maintaining the schema separately (with or without help from an ORM). When the schema changes, it is the application developer's responsibility to plan, sequence, perform and validate the schema update manually on the database.

Depending on which side your application is leaning towards, it is crucial to choose a data model that would take on most of the tasks and only bridge capabilities as and when needed.

Choosing the wrong data model would mean that the application has to handle many aspects that a database would provide by default.