And you are here why?

“Hard-Disks” — remember them? Yeah, old school, and all that, but so much (!) of what we take for granted in Database architectures derives from the limitations of hard-disks. The big,   huge , one, of course, is the difference in sequential and random access. Writing data sequentially is easy — the disk head moves to the appropriate location, and just starts writing block after block. Random writes, however, incur the additional — and huge! — latency associated with moving the disk head to the appropriate location. Extend this to your favorite database, and consider what this means for a transaction. Back in the hard-disk days, it was much,   much   simpler to write all the transaction’s changes into a single set of sequential writes (in a separate “log”. Hence “write-ahead logging”, or WAL) instead of a whole bunch of random writes at different locations. Enter the world of nonvolatile memory (NVM), which is pretty close to RAM speeds,   definitely , doesn’...

Chris Travers has a fairly nifty article up titled O/R Modelling interlude: PostgeSQL vs MySQL , where-in he makes the claim MySQL is what you get when application developers build an RDBMS. PostgreSQL is what you get when database developers build an application development platform. This isn't really flame-bait - its intended as a statement to show how people approach arguments (flame wars?) about MySQL vs PostgreSQL.  To paraphrase Chris, MySQL has been massively disruptive because it tends to really, really look at the world from a Use Case perspective, answering the questions " What problem are you trying to solve ", while Postgres has been massively disruptive because it tends to look at the world from a theory perspective, answering the question " How should the database work in the solution " I'd add MongoDB to this mix though, and extend the above quote to say MySQL is what you get when application developers build an RDBMS. PostgreS...