Is JSON in a database norm for relational databases?

Started by xerbotdev, Apr 05, 2023, 07:07 AM

Previous topic - Next topic

xerbotdevTopic starter

I realize that there may not be a definitive answer, so I am seeking an explanation rather than a straightforward response. In the context of non-relational databases, this approach is considered favorable. However, in relational databases, things become peculiar—the fundamental principle of such databases implies that there should be only one value for each field. Nevertheless, PostgreSQL supports the JSON format, which is objectively a more efficient solution in many cases. Certain members of the media even advocate for the adoption of such solutions.

Now, I have a couple of specific inquiries:

1. Can the JSON format be employed in situations of heavy load, or is it necessary to migrate to a different database?
2. How frowned upon is the practice of using JSON in relational databases? Is it strictly prohibited, sometimes permissible, or is it considered good practice?


If the field with JSON does not require frequent updates, it can be utilized without any issues.
However, it is important to note that this may not be applicable for fields that are linked to foreign keys or involved in selections.

Storing data without a defined structure or data that undergoes frequent structural changes is where utilizing JSON proves beneficial.
For instance, the outcomes of certain data collection processes can be conveniently stored within a JSONB field.


JSON serves as a string-format storage mechanism that enables the storing of multiple values with various types in a single cell. It is evident that actively working with such a format may lead to inefficiency, as each row may potentially contain a distinct set of values, which hinders effective searching.

However, if the data does not require extensive searching operations (i.e., no comparisons, unions, or sorting are necessary), and the data primarily consists of strings, then the performance impact is minimal. The specific requirements or intentions behind the query are unclear from the provided question.


I utilized JSON to store the color schemes for my application, encompassing elements such as the background color, font, and font size. Given that manipulating the data within the schema is a rare occurrence, I believed this approach to be feasible. While it was possible to decompose these attributes into separate fields, I found it more convenient to store and retrieve pre-made schemes as a whole.

Furthermore, I stored key-value pairs in text fields, effectively storing multiple pairs within a single field. By converting the map into a string representation using "map.toString()", I was able to save it and easily parse it back into a Map object. It seemed like a straightforward solution without encountering any major challenges.

Admittedly, as a beginner, I am not entirely certain if this is the correct approach. However, so far, it has served my purposes well without any apparent issues.


1. The performance of using the JSON format in situations of heavy load depends on various factors, such as the specific workload, the size and complexity of the JSON data being stored, and the specific database system being used. While JSON can offer flexibility and ease of use, it may not always be the most efficient solution for heavy load scenarios. In some cases, migrating to a different database system specialized for handling JSON data, or considering alternative data modeling approaches, might be necessary for optimal performance.

2. The practice of using JSON in relational databases is not strictly prohibited, but it is a topic of debate within the database community. Some argue that using JSON in a relational database undermines the principles of data normalization and structured querying. However, others contend that with proper planning and usage, incorporating JSON into relational databases can offer advantages like flexibility and faster development. Ultimately, the decision to use JSON in a relational database depends on your specific use case, performance requirements, and trade-offs you are willing to make. It's recommended to thoroughly evaluate the pros and cons and consider the opinions of experts in the field before making a decision.

Here is further information on the topic:

1. Performance Considerations: While JSON can be used in situations of heavy load, it is important to evaluate the specific performance requirements of your application and the capabilities of your chosen database system. JSON data can be efficiently indexed, queried, and updated in some database systems, but it may not perform as well as a specialized NoSQL or document-oriented database in certain scenarios. Depending on the complexity and size of your JSON data, migrating to a different database might provide better performance, scalability, and flexibility.

2. Usage and Best Practices: The usage of JSON in relational databases is not strictly prohibited, and it can be permissible or even considered good practice in certain situations. It largely depends on the nature of your data and the requirements of your application. If your data has a hierarchical or semi-structured nature, using JSON can offer advantages such as schema flexibility and easier handling of evolving data models. However, it's important to carefully consider the trade-offs, as using JSON in a relational database might make it harder to enforce data integrity rules, perform complex queries, and maintain structured relationships between entities. It's recommended to follow best practices such as using appropriate indexing and storage techniques, properly normalizing relational data where possible, and considering alternative data modeling approaches if needed.

Overall, the decision to use JSON in a relational database should be based on a thorough understanding of your specific requirements, performance considerations, and the capabilities of your chosen database system. It's always advisable to consult with experts or database professionals who have experience with similar use cases to make an informed decision.