The application uses JPA/Hibernate for persistence. The current behavior is that all aggregate roots are fetched from the database, updated by the application and then written back to the database with lots of update, delete, and insert statements.

Doctor, doctor, it hurts when I do this. - Well, don't do that.

ORMs will never figure out the use-case you're doing, use the additional information you know exists, or even use specific database features to the fullest. Therefore they always be sub-optimal for anything but trivial cases.

What you describe is a typical problem: fireing N statements when you know 1 would actually suffice.

Cut the "persistence agnostic" nonsense, and just model your problem properly. Don't let yourself be misled by the tools you use, or some arbitrary architecture that doesn't seem to fit your case anyway. Be free! :)

The application uses JPA/Hibernate for persistence. The current behavior is that all aggregate roots are fetched from the database, updated by the application and then written back to the database with lots of update, delete, and insert statements.

Doctor, doctor, it hurts when I do this. - Well, don't do that. ;)

ORMs will never figure out the use-case you're doing, use the additional information you know exists, or even use specific database features to the fullest. Therefore they'll always be sub-optimal for anything but trivial cases.

What you describe is a typical problem: fireing N statements when you know 1 would actually suffice.

Cut the "persistence agnostic" nonsense, and just fire the sql statement you need. Don't let yourself be misled by the tools you use, or some arbitrary architecture that doesn't seem to fit your case anyway. Be free! :)