It's pretty unlikely to get a collision[1], and the client should be able to handle the gracefully (regenerate the UUID and retry).
[1] https://www.quora.com/Has-there-ever-been-a-UUID-collision
[1] https://www.quora.com/Has-there-ever-been-a-UUID-collision
I was able to reproduce UUIDv1 collisions at will when the timestamp had microsecond resolution and the clock sequence had to be generated randomly each time. That is, I simply had to get two processes to generate the same fourteen bits within a microsecond.
It's a nasty corner case, but I'm sure the UUID designers considered it a valid tradeoff, since I believe the algorithm was designed for a distributed scenario. In the single-machine case an atomic counter would be a much easier solution with very reasonable efficiency anyway. Still, it might have been clever to also include the local process id in the UUID, I wonder why they didn't to that.
At any rate the problem is easily worked around by running the two processes on different machines, i.e. ensuring you have at most one UUID generating process per host (with respect to the database table in question).
unlikely is not zero, which was why I commented. I'd hate to rely on uniqueness of something that has a chance of not being unique.