Hello HomerJ,
The recommendations can vary depending on the situations and the availability of resources. the following would be the best recommendations for ease of use, availability of system, and most Straightforward and least chances of issues arising:

The number of DB instances needed would be dependent on the path you intend to take in the upgrade (also which version of ALM 12.x are you looking to upgrade to, as ALM 12.53 is the latest and most current but it not a direct upgrade path from ALM 11.0, only ALM 11.52)? There are many paths to get this resolution. No matter the method attempted, make sure that full backups are performed and in place before attempting any upgrade path.

1) If you intend to upgrade everything at once from QC10 to ALM 11.x, then upgrade everything from there to ALM12.x, and not ever have access to the QC 10 instance then you could just reuse the DB that is currently configured for QC10. You could get away with the original QC10 DB and just upgrade everything along the way by upgrading everything to ALM11 (all projects completely migrated) and once everything is completed then you could complete the migration to ALM12.x after (all projects completely migrated). You would just need to insure that the current DB instance is a fully supported instance for the ALM11.X AND ALM12.X versions. The downfall with this method is that everything must be upgraded fully to one version before moving to the newer version and once they are migrated there is no rolling back should there be an issue encountered. (I would not recommend doing this, but it is an option as once the migration is started there is no ability to get the QC10 back should issues arise except to completely reinstall QC10 and reimport the backups. Should issues arise you have no way to easily get the system back to a prior useable state and restore productivity to the users while trying to resolve the issues that may arise.).

2) The next option would be to have 2 DB instances, one for the QC10, the current one in use, and then another that would be used to migrate everything completely from the qc10 instance to the ALM11.x instance. Once the migration is completed to ALM11.x (all projects completely migrated) then the migration from ALM11.x to ALM12.x can be completed (all projects completely migrated). The DB instance chosen would need to support both the ALM11.x and ALM12.x versions fully.The downfall of this is that the migration must be completed fully to ALM11.x before attempting a migration to ALM12.x so should issues arise you could not incrementally upgrade products into ALM11.x and then migrate some to ALM12.x the entire process MUST be completed in ALM11.x environment before attempting to migrate further to ALM12.x. This would be a better option than 1, but not as good of an option as 3. This does allow the QC instance to remain up and operational should issues arise.

3) The final option would be to have 3 DB instance (the original QC10 instance, and one for each of the ALM11.x and ALM12.x versions). By having 3 separate instances you can incrementally be upgrading projects from QC10 to ALM11.x, and then further to ALM12.x. This option would allow for all 3 instances to be up and running the entire time so should issues arise in certain projects, you can then continue to upgrade other projects and eventually have the ALM12.x up and useable to users on some projects and also have problem projects still useable in QC10 while working through the issues in the ALM11.x environment and not hurting usage availability as much. You can pick and choose which projects to migrate and at which time to do so, and not have the entire environment committed and unavailable. This allows for better error/ issue recovery and limits downtime and increases availability. If you have the capability and resources this would be the recommended pathway with the best and easiest migration and the highest uptime and availability as you have