What data format to choose for storing entities (sql\nosql(json))?

Question

SQL

Hey!
There was a task to create base which would describe certain objects. Objects may have a number of properties that may be added in the future. For example, a property that describes a state, some properties can be in the form of a list. For example, the price for different categories of buyers. Now the number of such properties is about 8, with details (fields) - on 3 sheets of A4.
The number of objects is initially not very large - about 1000. But you need to plan sane work of at least 10k, or even better - a million (but there will already be the possibility of sectioning / grouping by region).
It should be possible to filter by object parameters.
So.
1. Make it a regular SQL solution.
Of the minuses - the need to stuff these tables, migrations (I will do it naturally with the help of EF),
Of the pluses - the simplicity of data sampling.
2. Combined solution, SQL table and Key-Value table (or use the MongoDB functionality)
Headers are stored in sql, for example, the article, title and some other trifle (several columns) and ID, by ID it is associated with a JSON document.
Pluses - relative simplicity of work with the data, as with objects.
Cons - lack of migration as such when renaming fields or changing types (including it was just an object, it became an array) - it's worse with migration.
Filtering - either fetching the entire database, or using tools in MongoDB to filter in JSON.
Yes, I would like to tie CQRS-ES in case of further development of the project. I don't know yet what it will be easier to screw it to.

Answer 1

For a million records, it doesn't really matter which solution you use.
If you start with pure relational SQL, then data where relationality is not needed can then be serialized and stored in binary fields of relational tables.
Using NoSQL, you will somewhat complicate your work, since it will be necessary to invent and impose indexes on collections in order to quickly make selections and count aggregates.
However, NoSQL has a notable advantage - out of the box, these storages can be quite well combined into failover clusters. True, the lack of transactions and eventually consistence will not allow you to be guaranteed to read the data that has just been written to the cluster.
Accordingly, a combined solution will combine the advantages and disadvantages of both worlds.

Answer 2

I would choose one.

Answer 3

There were a lot of articles on Habré about document databases, you need to read about all the limitations and birth injuries about them in advance. MongoDB is actively developing, but the very concept of document databases is very different from relational databases and you need to understand it, it is advisable to first practice on a home project.
All that is written in a relational form is easily implemented.