IMO, databases is often an integral part of the program and should be part of the test (a real database in a docker image).

For instance, if you are not relying on unique constraint in the DB to implement idempotency you are probably doing something wrong, and if you are not testing idempotent behaviour you are probably doing something wrong.

I have plenty of tests actually calling database. Maybe it is not a proper unit test, but it is not a problem for me.

I want test to protect me against regressions, and I do not really care how they are classified.

It really depends on your definition of unit. In the London school of TDD, no, a unit cannot extend across an I/O boundary. The classicist school takes a more flexible, pragmatic approach.

You mean fakes/stubs, right? Unless you're testing whether you're correctly implementing the protocol exchange with an external party, you don't need to record the API calls.

How do you test your mocks?