Using SHA-1 in this way, with a random seed and a counter, is just building a (perfectly sound) CSPRNG with, I believe, an 80-bit security level. If you trust the source of the random seed, e.g. /dev/urandom, you may as well just use /dev/urandom itself. If you don't, you're already in trouble.

I'd like to see actual benchmarks of /dev/urandom vs. a userspace PRNG before believing the argument that it's too slow. Some people (I seem to recall Chromium does this) have done the benchmarks, and use enough random data that they implement their own userspace PRNG. Most applications don't need it.

It's also possible that getentropy() on OpenBSD and GNU/Linux recovers enough of the performance. The system call path is extremely fast, and the kernel isn't doing random number generation any faster than you are -- unless you're doing a bad job of it.

And if you somehow need a userspace PRNG, the usual advice about not rolling your own crypto unless you know what you're doing applies. (Especially for database IDs, the risk of collisions should be considered a security problem, ergo this should be considered crypto, until proven otherwise.) In this case, using BLAKE2 instead of SHA-1 would get you a higher security level and faster hashing.

Or, in tptacek's words: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...