If database creation is slow compared to TRUNCATE, create a pool of databases
when each test finishes, it can truncate the DB, and marks that DB as unused in a synchronized in-memory set data structure
if a test starts and there is no free DB, it just creates the DB and adds it to the pool
Then you end up with databases named like:
Are you asking about integration/e2e tests or unit tests? For unit tests, the precision returned shouldn't matter, since you're providing those values directly to the test.
If you're talking about integration or e2e tests, ideally you'd run against all your supported DBs (maybe in ephemeral environments against containerized persistence layers), then ...