Protecting the key ("obfuscation" might be the wrong word) assumes that there is some attacker which should not see the real key and/or should not be able to use the key. Without such potential attacker (which might be the user itself) there is no need to protect the key in the first place.
Just guessing the key is in your scenario kind of impossible since the key is randomly chosen and large enough. But the key might somehow leak to somebody who should not be able to see the key in the first place or who should not be able to associate multiple uses of the key with each other.
For example it could be that the key represents some user, and that user details could be accessed just by knowing the key. In this case it might be a problem if the key gets exposed in the URL and ends up inside a
Referer header when doing some cross-site request. Or it might be that the key represents a user profile. Here would it be a problem if the same key is used on different sites, so that the user can easily realize that it gets tracked.
In these cases it might be useful to somehow protect the original database key. But simply using a fixed hash will not help: a specific key will always be mapped to the same hashed key. And when every access to the database will be based on the now protected key, then knowing the hashed key allows the same kind of access or associations than with the original key.
It would be different if the protection of the key was based on some additional and variable context. Such a context could for example be the current session id, in which case the protected key could only be used if the session id is also known. This would help against accidental leaking the key inside a
Referer. Or the context could be the current web site. This would help against the user realizing that no matter which web site they visit they will be tracked and it will always add up to the same user profile. Or the context could be the time so that the key could only be misused within a short time frame etc. If such protection is needed and how it should be implemented depends on the details of the specific use case.