Performance

Neither am I a database expert, nor do I think that mqttDB as of today scales well. mqttDB handles memory quite inefficient, the whole database is kept in memory in the core and all the worker processes.

A compromise between view composing speed and memory consumption can be made by increasing/decreasing the number of worker processes (see Command Line Parameters). Keep in mind that it makes no sense to have more workers than (logical) CPU cores, this would not result in a speed-up, this would just consume unnecessary extra memory.

mqttDB wasn't designed for storing gigabytes of data, millions of frequently changing documents or thousands of views. The concept was made with a couple of dozen views and a few thousand rarely changing small sized documents in mind. You should find out for yourself if it can deliver sufficient performance for your use case.

Due to the fact that mqttDB publishes all documents and views as retained MQTT messages, you have to be aware that this might - depending on the amount/size of documents/views and the subscription count - put significant load on your MQTT broker and raise its memory consumption.

Furthermore you should take care that your database clients only subscribe the topics they really need, it should be well considered if it's really needed to subscribe to $db/doc/#. A better approach could possibly be to create views that contains the ids of needed documents for a specific client, let the client first subscribe to that view and then subscribe only to the documents that are specified by the view.

TL;DR mqttDB can under circumstances put significant load on your MQTT broker and the memory consumption is many times over the database size.