There are two components to consider with this:
Thread-safety of go language client
The first one requires auditing, hopefully it is easy to find this information through the community without having to drop down into code level audits. I see that concurrent (thread) safety is mentioned for a number of the abstractions on the official go documentation so it should be easy to find which structs and methods are safe for concurrent use from a language level perspective (go).
Database Transaction Isolation Levels
The second is consideration starts to get into database and the guarantees that your specific DB offers (and just general distributed systems fun :) ) The default isolation level for postgres/mysql allow for 2 concurrent reads to see the same data, and then have each one overwrite the other (on a write).
The postgres documentation provides an excellent example of this case:
Because of the above rule, it is possible for an updating command to
see an inconsistent snapshot: it can see the effects of concurrent
updating commands on the same rows it is trying to update, but it does
not see effects of those commands on other rows in the database. This
behavior makes Read Committed mode unsuitable for commands that
involve complex search conditions; however, it is just right for
simpler cases. For example, consider updating bank balances with
transactions like:
BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;
If two such transactions concurrently try to change the balance of
account 12345, we clearly want the second transaction to start with
the updated version of the account's row. Because each command is
affecting only a predetermined row, letting it see the updated version
of the row does not create any troublesome inconsistency.
