In what language? Unit testing uses whatever DB client comes with your stack, and those clients have generic interfaces.
For example, they will transparently decode UUIDs into strings when you read them, and then they will write them back as the database's UUID type when writing. As far as your code is concerned, they were always just strings.
The same is true of dates for mainstream, mature stacks.
> Stick to the commonly supported set of SQL data-types.
Postgres is among the most vanilla SQL implementations. UUID/GUID/uniqueidentifier is available in every modern SQL-based RDBMS.
Refusing to use the idioms of your database is a guaranteed way to lose performance for no reason.
In languages like Go, Java and C++. The product in question is an integration product where customer can configure choice of database in public/private cloud.
Using basic SQL types that have common support across all database vendors simplified development, testing and support. I have seen folks waste weeks (to months!) in data migration/porting and still lose time troubleshooting issues across databases when they used db specific features. Too much tech debt incurred.
Loss of minimal performance weighed against simplicity and maintainability and no vendor lock-in. When you have the same tests and same schema and same DB layer code working against multiple databases, life becomes wonderful and hassle free.
Because many customers have their own expertise in the database system of their own choice. A shop that has hired Oracle DBA's doesn't want to hire Postgres folks. A MySQL based place doesn't want to hire Oracle folks. And they already have built extensive data-management processes around their choice of database systems and have the in-house experience to manage their database system in a wide variety of platforms.
If you to sell a packaged, deployable product to the widest market, yet want to minimise support, you leverage the expertise that the customer already possesses.
This is probably more of a consideration in the business enterprise space than some simple normal end-consumer SaaS, so I am not saying this approach makes sense everywhere.
In what language? Unit testing uses whatever DB client comes with your stack, and those clients have generic interfaces.
For example, they will transparently decode UUIDs into strings when you read them, and then they will write them back as the database's UUID type when writing. As far as your code is concerned, they were always just strings.
The same is true of dates for mainstream, mature stacks.
> Stick to the commonly supported set of SQL data-types.
Postgres is among the most vanilla SQL implementations. UUID/GUID/uniqueidentifier is available in every modern SQL-based RDBMS.
Refusing to use the idioms of your database is a guaranteed way to lose performance for no reason.