Doing the deletion before the commit means that if the commit fails, you're left with a row that refers to a non-existent file. If that's a problem, then it's b

Doing the deletion before the commit means that if the commit fails, you're left with a row that refers to a non-existent file. If that's a problem, then it's better do the deletion afterward. And not just "step 1, commit to the database, step 2, erase the file from S3", because a failure between those steps will cause files to be left orphaned on S3. A good system would be to mark the row as having its file soft-deleted, and have a task the regularly looks for rows marked soft-deleted, make sure the file is deleted from S3, and then mark the row as actually deleted.