Multiple domains on a single DB has lots of advantages like being able to share browses, metrics etc.
A key benefit is the ability for custom browses to report accross-domains rather than just the users current domain. Eg to see each others inventory. This can be useful for intercompnay trading (back-to-back orders) becuase the buying site browse for their purchase orders could also show the status of the supply site sales order. And visa versa.
A major consideration for multi-domains on a single DB is how to introduce a new additional domain to an already-live DB. At the start of a new domain project you might take the current prodcution DB and copy it to your test server. Add the new domain and begin to configure, populate data and test things out. But 2 months later when you want to now "refresh" the data of the existing domains there is no mechanism to keep the new domain (that is not yet in prodcution), it all gets overwritten withe the fresh copy of Prod DB. So you have to start the new domain all over again in Test (base data, etc). Similarly, if you now have the perfect set of base data in Test, there is no mechanism to copy that to Prod when you want to go-live.
My suggestion would be to automate all data-entry, you can practice using the automated data-entry on test as often as you like, and when proven, can re-run the same automated data-entry on production. This elimintaes a lot of the "oh, I forgot that" issues when going live and the same mechanism can be used on a daily copy of yesterdays data to give the chance to test on close to real-world data which is very useful for users.
If you go for mutliple DB, for the later ones you might choose to implement a later version (after all QAD are always adding new features that are nice to have), now you have multiple code-bases to maintain too, with separate patches etc. And while most browses will be compatable, you have to copy between, set up menus, access permissions etc. Risk of the same browse number being different in different DBs (or different version of same browse different in different DBs). All avoided if you stick with one sahred DB.
Overall, my personal preference would be single DB for all the shared benefts this brings. Good luck