Wouldn't the testing basically consist of executing large amounts of SQL against an initially empty database, and then executing more SQL to read the current state of the data and verifying it is like it should be?
Such tests could perhaps be database-agnostic to a degree, verifying that the database behaves according to the SQL-standard?
Those are the easiest tests to write, and probably pretty unlikely to find anything unless the feature you're adding is exposed via SQL pretty directly.
I was thinking more like lots of concurrent operations, and backups/restores (again concurrent with other DB traffic), and replication, and incremental operations, and failover, and error handling in general. All while varying things that feed into scheduling, etc. Anything nondeterministic is good, though that's not all of it. (Annoyingly, that means that failures will quite often be intermittent, which is a whole can of worms of its own.)
Such tests could perhaps be database-agnostic to a degree, verifying that the database behaves according to the SQL-standard?