And you are here why?

Here’s a quick one —  Do you know how many code-bases DB/2 has? The obvious answer, of course, is — or should be! —  ONE , right? Well, it turns out that the actual answer is   FOUR , one for each of their (major) product lines, viz, the   AS/400 ,   MVS , and   R/6000   (as well as one for   VM , but more on that in a bit). As to “ Why? For gods sake, WHY SO MANY CODEBASES? ”, it really comes down to  Mechanical Sympathy . Each of IBM’s hardware lines has dramatically different hardware/OS models. For example, the AS/400 line uses a seriously flat memory model, where memory and disk addresses are indistinguishable, and objects move transparently between them. What’s more, the  whole system is capability based  (pointers to an object in memory/disk include the security permissions necessary to get at them). The R/6000 line, OTOH, very much does  not  have this  . And that takes us directly to the  tradeoff betw...

Database technology for transaction processing and that for analytics have, kinda, moved in different directions. This has largely been from a “separation of concerns” perspective . Transactions are all about velocity, with people speeding up databases by making them in-memory (e.g. HANA), and/or adding columnar capabilities (e.g. Postgres, Oracle, and, well, everybody). Analytics, OTOH, are usually about volume — having   massively parallel   or distributed back-ends that can run through gobs of data very fast (e.g. Vertica, Redshift, Netezza, etc.) is pretty much table-stakes in this world. Mind you, when one talks about   massively parallel , GPUs should come to mind, and it clearly did for   Kinetica ,   SQream , and   MapD   who are all using GPUs to run the parallelized parts of SQL queries in their analytics databases. The result, as you might imagine, is a   huge   speed up in query processing for analytics. MapD, in partic...