I would say that for my current project, is is not so much the case that we intended to design our system “database first”, but rather that we were forced into this perspective for performance reasons. Initially the project was using Django-REST model objects, but as the system developed we found more and more that we were having to write raw SQL to get acceptable latency; Increasingly we found ourselves fighting the ORM to get it to do what we wanted.

For example, our app behaves like a version control system, keeping track of all past versions of every record; committing a pending change requires updating a lot of records in a single transaction, but only a single column is changed, and there’s no need to load those records into memory. There are many other operations (such as “check out at version” and “rollback”) which operate on large numbers of records.

During my eight years at Google, I never used an ORM since Google doesn’t generally use relational databases; however, there were similarities in the way that data was handed. For example, the GMail contacts database (which I worked on) has hundreds of columns, used by dozens of different apps (basically it’s the same database that stores the G+ social graph); no single app ever used all of those columns. These apps used Google protocol buffers for their in-memory representations, which were technically “objects” but had no business logic in them.

However, I would prefer to minimize the importance of my personal anecdotes; my opinions about ORMs have largely been influenced by reading tech articles from other engineers who have had similar complaints.