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

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.


  • Actian logo
  • AEROSPIKE logo
  • AWS logo
  • ArangoDB (logo)
  • Cambridge Semantics (logo)
  • COUCHBASE logo
  • logo
  • DataStax (logo)
  • ESGYN DB logo
  • FAUNA logo
  • Franz Inc (logo)
  • Grakn logo
  • GRIDGAIN logo
  • IBM (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
  • VOLT DB logo

These organisations are also known to offer solutions:

  • Broadcom
  • SAP
  • Teradata
Cover for EsgynDB and HTAP

EsgynDB and HTAP

This paper discusses the sorts of features needed to support HTAP processing and then considers the capabilities of EsgynDB within this context.
MARK LOGIC InBrief cover thumbnail

MarkLogic Data Hub Service and MarkLogic Server

MarkLogic Server is a multi-model database that can be used to store documents, relational data via tables, rows and columns, and graph data.
SPARSITY InBrief cover thumbnail

Sparsity Technologies Sparksee

Sparsity Technologies Sparksee is a property graph database that focuses on high performance deployment at scale and on embedded systems.
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.
TIMESCALE InBrief cover thumbnail


TimescaleDB is built on top of PostgreSQL as a database intended to specifically support the requirements of time-series data.
REDISGRAPH InBrief cover thumbnail

RedisGraph (2020)

RedisGraph is the graph database module for Redis where, by “module” the company means functionality embedded into the product.
00002473 - INTERSYSTEMS InBrief cover thumbnail

InterSystems IRIS

InterSystems IRIS contains a multi-model database that stores data in multi-dimensional arrays.
REDIS ENTERPRISE InBrief cover thumbnail

Redis Enterprise (June 2019)

Redis is an in-memory, multi-model database platform.
Back To Top