Actually transactions can be a secomd-layer safety-net for single-responsibility writers to ensure rollback on eg restarts and consistency on loadbalancer redecisions without having much of an impact on performance, and data integrity is usually quite important.
As long as the database is acid restarts should not be a factor. Data integrity is not helped by transactions, you would need error correcting codes for that. Plus the effect on performance is quite notable on all dbs I’ve worked with.
Restarts in a server between dB updates that in a sane world would be txns I meant (e.g update A, crash so don’t update B). Anyway, in postgres they’re pretty cheap in the absence of actual conflict – more expensive if you have actual cinflicts, obvs.
Actually transactions can be a secomd-layer safety-net for single-responsibility writers to ensure rollback on eg restarts and consistency on loadbalancer redecisions without having much of an impact on performance, and data integrity is usually quite important.
As long as the database is acid restarts should not be a factor. Data integrity is not helped by transactions, you would need error correcting codes for that. Plus the effect on performance is quite notable on all dbs I’ve worked with.
Restarts in a server between dB updates that in a sane world would be txns I meant (e.g update A, crash so don’t update B). Anyway, in postgres they’re pretty cheap in the absence of actual conflict – more expensive if you have actual cinflicts, obvs.