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.

Relevant Analyst
Andrew Brust

Andrew Brust

Research Director Gigaom Research

Do you want to speak with Andrew Brust about this topic?

Learn More
You must be logged in to post a comment.
No Comments Subscribers to comment
Explore Related Topics

Latest Research

Latest Webinars

Want to conduct your own Webinar?
Learn More

Learn about our services or Contact us: Email / 800-906-8098