Should I use noSQL for catalogs with filters (products, real estate and everything in a countable amount)?

Question

SQL

Compared to MySQL, what are the pros and cons of using non-relational noSQL databases for sites whose main content is catalogs with filters (products, real estate, articles and everything in a countable amount)
, in particular, they are interested in: 1. speed of work 2. ease of use and entries with React JS library

Answer 1

We store data in MySQL (or rather PostgreSQL, because this could be the end), we do data aggregation in mongodb / couchdb, we use mongo for selections, for recording - mysql + again we start data aggregation.
Monga gets sad when you try to make joins there. And if you want to make mongus the main repository, then you will want to make joins ... such things. As a caching layer - nice. As the main base - you need to think very well whether it's worth it.

Answer 2

IMHO, your question is too general.
The speed of work depends on how you cook, it makes no sense to consider the average for the hospital.
For catalogs with a large number of diverse products, it can be difficult to maintain an up-to-date relational database structure to store all possible options for properties. In this case, the noSQL database can be useful by the formal absence of a schema.
noSQL databases also make it easier to implement multiple searches. For example: habrahabr.ru/company/2gis/blog/213765/.
To work with React, you will probably need to generate or parse JSON on the server side. It seems to me that it is not worth it just because of this to become attached to some particular type of database.

Answer 3

postgres is our everything
If you want fyr-fr-fr only in the frontend and don't want to toil as a backend, then you should look for keywords like backend-less backend-as-a-service
Just keep in mind that NOSQL solutions are good for a thin layer of tasks and volumes of data. Bigdata needs its own solutions and its own files