Operational database management systems (also referred to as OLTP databases or online transaction processing databases), are used to update data in real-time. These types of databases allow users to do more than simply view archived data. Operational databases allow you to modify that data (add, change or delete data), doing it in real-time.[1] OLTP databases provide transactions as main abstraction to guarantee data consistency that guarantee the so-called ACID properties. Basically, the consistency of the data is guaranteed in the case of failures and/or concurrent access to the data.
Since the early 1990s, the operational database software market has been largely taken over by SQL engines. In 2014, the operational DBMS market (formerly OLTP) was evolving dramatically, with new, innovative entrants and incumbents supporting the growing use of unstructured data and NoSQL DBMS engines, as well as XML databases and NewSQL databases. NoSQL databases typically have focused on scalability and have renounced to data consistency by not providing transactions as OLTP system do. Operational databases are increasingly supporting distributed database[2] architecture that can leverage distribution to provide high availability and fault tolerance through replication and scale out ability.
The growing role of operational databases in the IT industry is moving fast from legacy databases to real-time operational databases capable to handle distributed web and mobile demand and to address Big data challenges. Recognizing this, Gartner started to publish the Magic Quadrant for Operational Database Management Systems in October 2013.[3]
Notable operational databases include:
| Database platform | Database model | SQL Support | NoSQL Support | Managed objects | ACID-transactions | |
|---|---|---|---|---|---|---|
| Key–value store | No | Yes | key-value pairs | None | ||
| Relational database | Yes | No | tabular data | ACID transactions | ||
| Key–value store | No | Yes | key–value pairs | None | ||
| Apache HBase | Key–value store | Yes (Phoenix) | Yes | key–value pairs | ACID-transactions | |
| Document-oriented database | No | Yes | JSON | None | ||
| Document-oriented database | Yes (essential SQL) | Yes | XML, JSON, text data | Distributed ACID-transactions | ||
| Relational database | Yes (newSQL) | No | tabular data | ACID-transactions | ||
| Document-oriented database | Yes (N1QL) | Yes | JSON, key–value pairs | Distributed Multi-Document ACID transactions | ||
| Document-oriented database | No | Yes | JSON | None | ||
| Relational database, Data Warehouse | Yes | Yes | JSON, key–value pairs, tabular data, XML | ACID-transactions | ||
| Relational database | Yes | No | tabular data | ACID-transactions | ||
| Key–value store | Yes | No | key–value pairs | ACID-transactions | ||
| Relational database | Yes | No | tabular data | ACID-transactions | ||
| Document-oriented database | Yes | Yes (XQuery and JavaScript) | XML and JSON | ACID-transactions | ||
| Relational database | Yes | No | tabular data | ACID-transactions | ||
| Document-oriented database | No | Yes | BSON | None | ||
| Relational database | Yes (newSQL) | No | tabular data | ACID-transactions | ||
| Relational database | Yes | Yes | multi-model | ACID-transactions | ||
| Document-oriented Database | Yes | Yes | key–value pairs | ACID-transactions[4] | ||
| Key–value store | No | Yes | key–value pairs | None | ||
| Relational database | Yes | No | tabular data | ACID-transactions | ||
| Key–value store | No | Yes | key–value pairs | None | ||
| Relational database | Yes (newSQL) | No | tabular data | ACID-transactions | ||
| Relational database (YSQL), Key–value store (YCQL) | Yes (newSQL) | Yes | tabular data, JSON | ACID-transactions |
Operational databases are used to store, manage and track real-time business information. For example, a company might have an operational database used to track warehouse/stock quantities. As customers order products from an online web store, an operational database can be used to keep track of how many items have been sold and when the company will need to reorder stock. An operational database stores information about the activities of an organization, for example customer relationship management transactions or financial operations, in a computer database.
Operational databases allow a business to enter, gather, and retrieve large quantities of specific information, such as company legal data, financial data, call data records, personal employee information, sales data, customer data, data on assets and many other information. An important feature of storing information in an operational database is the ability to share information across the company and over the Internet. Operational databases can be used to manage mission-critical business data, to monitor activities, to audit suspicious transactions, or to review the history of dealings with a particular customer. They can also be part of the actual process of making and fulfilling a purchase, for example in e-commerce.
In data warehousing, the term is even more specific: the operational database is the one which is accessed by an operational system (for example a customer-facing website or the application used by the customer service department) to carry out regular operations of an organization. Operational databases usually use an online transaction processing database which is optimized for faster transaction processing (create, read, update and delete operations). An operational database is the source for a data warehouse. Data from an operational database can be loaded into an operational data store at a data warehouse before the data is processed into the data warehouse.