They definitely would have been true for any local database, if you include memory snapshot into the backup. I don't know a generic virtualization backup technology that does that.
Without this, next best backup procedure includes snapshotting all the storage at the exact same instant of time and storing the snapshot. It would be seen as a sudden power reset by the OS if you restore the VM from that backup. Therefore, any database that can withstand a sudden machine reset will be properly recovered with such backup technique.
So here it depends on the database. Any fully ACID database engine, such as PostgreSQL, Oracle, or MySQL's InnoDB, will survive the backup, because it's exactly what "D" in the acronym means, durability. Notice that it isn't guaranteed for other MySQL's engines, for example, I am not sure MyISAM is ACID.
The problem with such backup for the database is not that it is insufficient in terms of storing the database contents. It is not the reason why it is not employed often for the most important databases. One of the real problems is, this way of backup procedure puts more load to the system, because it needs to basically read all the database disk images every time you backup, which strains storage, which is already a weak point of a loaded database. Another is that it is also very demanding to use: you have to provide the exact same resources if you wish to restore from the backup and that procedure is also quite consuming, both in terms of time and load.
Mind you, not every restore from the backup is performed to recover from the total loss of the system. In most cases, you need to retrieve a few bits of the backup, such as a few WAL segments/archive logs (that's the same thing named differently in different databases), and it's a waste to recover and spin the entire VM just for that. Some advanced backup systems (Proxmox Backup when paired with Proxmox VE) can partially alleviate the problem since they can parse filesystems in the backup image and retrieve individual files and also run the VM early while it is still being recovered from the backup, but I wouldn't recommend depending on that possibility.
More straightforward backup techniques such as only backing up these WALs all the time and only doing full backups not very often incur a less IO load on the system and require less backup storage, but also have other compelling advantages, such as possibility of a point in time recovery, possibility to efficiently combine backup with HA (completed WALs can be copied to the standby systems and to backup simultaneously, which is the basis for the most HA database setups, everything else is built on top of that). On the other hand, backups by exporting databases are more useful, because they allow you to spin the database on entirely another system, recover individual tables and so on, while being also less consuming.
So, overall it depends on the purpose of the VM and the database in it, but for many cases, consider backing up the database individually, as recommended by the database vendor, in addition to backing up the VM image infrequently.
