skip to Main Content

Operational Databases

Last Updated:
Analyst Coverage:

An operational database is designed to run the day-to-day operations or transactions of your business. It may also be called upon to support analytic processing either by providing real-time dashboards or supporting the ability to embed analytics into operational processes.

There are many ways to skin this particular cat. Historically, the most common type of database used to support operations were relational databases, but some companies still run their transaction processing on navigational databases. More recent introductions include NewSQL databases (which look relational but aren’t) and various types of NoSQL database including, but not limited to, both graph databases and SQL on Hadoop engines. Many of these are suitable for supporting hybrid operational and analytic processing.

A report on HTAP databases and technologies will be published here shortly.

We regard operational processing as a superset of transaction processing. The principle difference from a database management perspective is with respect to the consistency of your processes. In our view – others may disagree – genuine transactions require immediate consistency while operations can leverage eventual consistency. This needs to be explained.

Apart from performance and other generalised considerations the major requirements for transaction processing – as opposed to operational processing – are so-called ACID properties and, typically, support for XA-compliant two-phase commit (where an XA compliant driver is a driver that can participate in an XA compliant transaction as defined by the X/Open specification). The former are properties that ensure that transactions are processed reliably, and the latter specifically supports atomicity (the A in ACID), ensuring that all transactions are either completed in full or rolled back.

However, consistency is a fraught issue when it comes to discussing distributed NewSQL and NoSQL databases, because of the CAP (consistency, availability and partition tolerance) theorem. While ACID provides guarantees about the processing of transactions within a database, the CAP theorem, also known as Brewer’s theorem, states that in a distributed data store you cannot guarantee all elements of CAP and, in particular, you can have availability guarantees or consistency guarantees but not both. Note that this isn’t an issue when the cluster is running normally.

One difficulty that arises is that the “C” for consistency in ACID is not the same as the “consistency” in the CAP theorem, which actually stands for “atomic consistency”. As the authors of the CAP theorem state: “discussing atomic consistency is somewhat different than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a different meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent.”

On top of this confusion of terms, there are multiple types of consistency (à la CAP) supported by different vendors. There is strong consistency, weak consistency, immediate consistency, eventual consistency, strong eventual consistency, causal consistency and a whole bunch of other consistency models. In addition, you will hear vendors referring to linearizability, which provides guarantees about single operations performed on single objects and is related to the CAP Theorem; and serializability, which refers to guarantees about transactions and is ACID related. There is also a concept known as strict serializability. Note that some vendors offer tuneable consistency, by which they mean that you can choose different consistency models depending on requirements, including having different models in place within the same cluster.

In this context, a useful resource is https://jepsen.io/analyses.

The short answer is everybody. Every organisation deals with at least some customers (or clients, patients and so on), partners, suppliers, staff, stock and so forth and operational databases are the bedrock upon which applications supporting these (often commercial) relationships are based.

In practice, the decision of which database to select will often be down to IT, if for no other reason than that it is the applications built on top of the database that the enterprise will interact with.

The most notable longer-term trend is towards the adoption of NoSQL and graph databases for particular use cases and, where, geographically distributed databases are required, also to NewSQL databases. This has been exacerbated by increased cloud and hybrid deployments. In the shorter term, there has been a significant uptick in interest in so-called HTAP (hybrid transactional and analytic processing) databases. These are not only provided by vendors of all the types of database already mentioned but also by providers of data grids.

Two further trends are towards the separation of storage and compute, allowing either to be scaled (preferably in an elastic manner) without reference to the other, and in the growth of multi-model databases – see NoSQL databases.

There are more than 350 databases on the market and the vast majority of these support operational processing if not transactional processing. A great many support both. In our view, this is too many, but which ones are set for a fall and which ones will live long and prosper is a question we can’t answer.

Solutions

  • Actian logo
  • AEROSPIKE logo
  • AWS logo
  • ArangoDB (logo)
  • Cambridge Semantics (logo)
  • COUCHBASE logo
  • CRATE.io logo
  • DataStax (logo)
  • ESGYN DB logo
  • FAUNA logo
  • Franz Inc (logo)
  • GIGASPACES logo
  • Grakn logo
  • GRIDGAIN logo
  • IBM (logo)
  • INTERSYSTEMS logo
  • LEANXCALE logo
  • MARIADB logo
  • MARK LOGIC logo
  • Memgraph (logo)
  • MONGO DB logo
  • N5 logo
  • Neo4j (logo)
  • NuoDB (logo)
  • Objectivity (logo)
  • Ontotext (logo)
  • QUASAR DB logo
  • Redis Labs (logo)
  • SingleStore logo
  • SPARSITY logo
  • Stardog (logo)
  • TigerGraph (logo)
  • TIMESCALE logo
  • VICTORIAMETRICS logo
  • VOLT DB logo

These organisations are also known to offer solutions:

  • Broadcom
  • SAP
  • Teradata
00002491 - VOLTDB InBrief cover thumbnail

VoltDB

VoltDB uses a shared-nothing architecture to achieve database parallelism, with both data and processing distributed across all the CPU cores within the servers composing a VoltDB cluster.
00002516 - MemSQL InBrief cover thumbnail

MemSQL (January 2020)

MemSQL is a scale-out distributed database, with a lock-free architecture that supports both row and column storage. They target Fortune 1000 companies.
TIGERGRAPH InBrief cover thumbnail

TigerGraph (June 2019)

TigerGraph is a native graph parallel database that is available both in on-premises and cloud versions.
IBM INFORMIX InBrief cover thumbnail

IBM Informix

IBM Informix is an object-relational database with native support for both time-series and geospatial data.
00002473 - INTERSYSTEMS InBrief cover thumbnail

InterSystems IRIS

InterSystems IRIS contains a multi-model database that stores data in multi-dimensional arrays.
Cover for IBM Informix on Cloud

IBM Informix on Cloud

This paper discusses the use of the IBM Informix database in the cloud and, more particularly, within hybrid cloud environments.
REDIS InBrief cover thumbnail

Redis Enterprise (February 2020)

Redis Enterprise is an in-memory, distributed (automated partitioning), NoSQL database with a key-value store as its underpinning.
CRATE DB InBrief cover thumbnail

CrateDB (June 2019)

CrateDB is targeted specifically at IoT applications and ingesting and processing machine data, and it can be deployed both at the edge and more centrally.
Back To Top