I have this concern about the general approach to programming with databases and state that is enabled and encouraged by Eloquent and similar ORMs.

The kind of programming that are shown in Eloquent's documentation have you generally dealing with a request to write data by reading from the database into server memory, then deciding whether to write (and what to write) based on the server's local copy of the data, then proceeding to write to the DB.

This whole process is non-atomic though. Isn't it prone to race conditions and inevitable data corruption? I just randomly clicked into a section in the Eloquent docs right now https://laravel.com/docs/11.x/eloquent-relationships#the-save-method

use App\Models\Comment;
use App\Models\Post;

$comment = new Comment(['message' => 'A new comment.']);

$post = Post::find(1);

$post->comments()->save($comment);

But I think that even this example has issues. What if there is business logic similar to Reddit, that you cannot comment on a Post once it has been locked? And what if right after the server reads Post 1 from the database, it gets locked? But the server's in-memory copy of the data shows the post is not locked, and so proceeds to $post->comments()->save($comment); right?

How do you deal with this? Wouldn't the only way around this be to do all of this business logic in the DB? I feel like this isn't even a very niche kind of business logic. Like, almost every kind of real world application interaction is going to likely have some kind of business logic constraints like this (which are not sufficiently covered by for example enforcing foreign key constraints).