>who has ownership of the database and data I absolutely loathe projects that communicate via shared database. It completely ties the hands on everything that

>who has ownership of the database and data I absolutely loathe projects that communicate via shared database. It completely ties the hands on everything that touches it. Data should be shared via an API, so that the underlying representation can be migrated, updated and changed and the API can munge up the new reality of the data to still look like the old. You should be able to switch between backends with a environment variable update, allowing your project to run in-memory, against sqlite, or against whatever actual relational or document store you plan to use in production. ORMs are "easier", in that they can get code running faster, but I've seen a good number of teams write the most atrocious code because the abstraction allows them to not think about things. Code that manages to fire tens of thousands of queries in loops instead of doing a single large query or walking the data in a conscious and efficient manner. It is my opinion that a single object inside of a project should wrap the database, each query thereto being represented by a function that, once again, can allow the underlying representation to change without the rest of the code being aware. ORMs are far too tightly bound, and teams using them likely to spatter ORM code all over the codebase instead of neatly arranging it behind a properly cut abstraction.