Isolation levels and locking

Isolation levels decide what transactions running at the same time can see of each other. PostgreSQL's default is Read Committed. Each statement sees data committed before it started, so two reads in one transaction can return different values.

Repeatable Read gives the whole transaction one fixed snapshot of the data. Serializable makes transactions behave as if they ran one at a time, but some will fail and must be retried. For "check, then update" logic you have two options.

You can lock the row with SELECT ... FOR UPDATE. Or you can use optimistic locking: a version column that the UPDATE checks has not changed. Without either, you risk a lost update, where one write silently overwrites another.