The convergence of transactional and analytic databases

In a database market that uses terms like “time to insight,” it’s clear that buyers and vendors are keen on eliminating data-analysis delays. Reducing the time between data being captured in transactional databases and its availability for analysis is key. Is the notion of having separate databases for transactional and analytics work going the way of the Dodo?

This week, Oracle’s Larry Ellison made it clear that he thinks so, as he pitched Oracle’s Database In Memory Option, an add-on to Oracle 12c. Ellison explained that the Oracle database now permits all data to be stored in both row- and column-store formats — the former being the conventional approach for an operational database, and the latter being de riguer for dedicated data-warehouse platforms.

Oracle is not the only industry player advocating for this data-workload-convergence. SAP, which introduced its fully in-memory HANA database in 2010, has made this argument integral to its marketing message. For its part, HANA uses the column-store architecture for most tables in its databases, and can execute queries written in both SQL and MDX. The latter stands for multidimensional eXpression language and is purpose-built for OLAP (online analytical processing) queries.

Microsoft has adopted the colocated row/column store approach as well: The Enterprise Edition of SQL Server gained columnstore indexes with the product’s 2012 release, though they were read-only replicas of the table data. The 2014 version of SQL Server, which went into general availability in April, added clustered columnstore indexes (CCIs), which are fully read/write and act as the sole store for a table’s data, rather than a copy of it.

NewSQL entrant MemSQL also combines column and row store technologies in a single database. More to the point, this trend will likely gain further momentum in the market. Increasingly, customers don’t want to maintain separate databases for analysis. They don’t want the extra moving parts, they don’t want to deal with the delays and fragility of the data movement and transformation process, and they are tiring of the need to create and perpetuate separate data models for analytics, especially when various business units in the Enterprise will likely come up with their own models anyway.

It’s not that we’re breaking up with analytical databases — it’s just that they’re moving in.