Breaking up the Monolith: Database Architecture for Developers
Use knowledge of database architecture to clarify some of the discussion around NoSQL and ORMs, avoid wasteful designs, find common ground between various database systems, and choose the right tools for development.
What parts of PostgreSQL are relational? Which piece guarantees ACID semantics? How much of PostgreSQL do you need just to do a simple CRUD application? Why is it so challenging to distribute a database system across many nodes? Are you reinventing a tool that already exists? Conversely, are you paying (in development time, administration overhead, execution time, etc.) for features you don't need? What if the SQL system that I use does not fit this architecture (e.g. SQLite) -- what does that mean? What if the NoSQL system I use started out looking radically new, but is looking more and more like SQL every day?
In addition to answering these questions, this talk will help you help you ask similar questions at the right time (that is, before you write the code), and detect dubious designs that are redundant and wasteful.