It's what you end up doing even with a relational database, because the database's built-in implementations aren't controllable enough. There's definitely space for a library that offers standard implementations of these things rather than everyone implementing it themselves from scratch, but applications need a lot more control over them than a traditional database gives them.

You end up rebuilding transactions, foreign keys, MVCC and similar features on relational db's? If so you're probably doing way to much work.

> You end up rebuilding transactions, foreign keys, MVCC and similar features on relational db's?

Yes, because the database-level builtins are too restricted; pretty much the only behaviour you can get out of them is "reject the change and throw away the data" which is almost never what you want, and requires you to keep the data around on the client side and hope that all clients implement recovery consistently. Think about the user-facing behaviour that you want when e.g. one user tries to join a group at the same time as another user deletes the group. It ends up being easier to implement the right thing without using database-level transactions and foreign keys.

> Think about the user-facing behaviour that you want when e.g. one user tries to join a group at the same time as another user deletes the group.

You join first and the group gets deleted or the group gets deleted and you can't join. I don't see the issue.