What is Mutable Data?

Mutable data refers to a database structure in which data can be changed. Any data changes made simply overwrite and replace the previous record. This means that previous iterations of data are lost unless there is a system of back-ups and transaction logs that track changes. Mutable databases are record-based, so there are limited spaces for data.

Types of mutable databases include relational database structures, SGL databases, and NoSQL structures. They form the majority of traditional databases, and for many organizations, this is the basic database formed when the organization sets up their systems. They are a traditional method because they originated in the era when data volumes were smaller, more expensive to store, and systems were transactional.

In contrast, immutable databases are the newer data forms becoming more common. The data points are not changeable; it’s assumed data and objects should not be modified once created. These databases are log-based, and simply create new spaces for additional data as it appears. These databases are more flexible in response to modern business practices, the huge amounts of data available now, and the affordability of cloud based storage.

When is Mutable Data Used in Business?

There are a range of databases used in business that are mutable. For example, in a database of customer details, the mutable data is information like phone numbers and addresses: when the customer’s details change, the new details overwrite the old ones.

Any database that requires updates, changes, and needs to easily comply with GDPR standards will have mutable data.

Also, think about the Internet of Things (IoT) and the sheer volume of data produced by every watch, refrigerator, and car in the world. Is all this data required? Storing vast amounts of data places a huge strain on systems and needs massive processing power. Does all of this data need to be permanently stored, or can it be removed and deleted once a new record arrives?

While some information needs to be recorded for service or maintenance reasons, some information might only need to be stored for 24 hours, or simply replaced with new information when it arrives. For instance, security systems recorded to the cloud often have limited plans, where new data is recorded and replaces old data every 24 hours or week. These are a form of mutable data.

GDPR Requirements in Databases

Data privacy is a huge challenge in today’s data-centric world. So much information is collected about people, and the European GDPR privacy laws made a bold step forward into legislating how and what businesses can do with this data.

GDPR Article 17 requires “the right to be forgotten.” In full, the legislation requires that any company with data about individuals from the EU must be able to erase all personal data at the request of the customer. This is simple with mutable databases; once the information is deleted, it is gone.

But this creates a larger challenge for organizations because immutable data is often needed. Historical data is required in some instances like banking records, medical records, and insurance data. Deleting the previous iterations of data could be catastrophic. The lack of history by deleting mutable data altogether can not only cause noncompliance but also huge problems with interoperability.

Crypto-Shedding Could Be the Answer

Crypto-shedding key management services are used to encrypt, control, and keep unique keys safe. It creates an encrypted list within the database. If there is a need to forget the data, the encryption is over-written, breaking the link to immutable data. This can also be implemented at a granular level, to only forget certain levels or fields of customer data. This means that both immutable and mutable data can be managed with the same tool.

This is one of the ways that businesses can meet GDPR requirements and get around mutable data challenges.

Benefits of Mutable Data

Quick and Simple

Because one form of data is simply replacing another, data tables don’t get bigger. This means that recall of data is fast and will remain so. There is also less complexity as there is only one copy of information.

Lower Hardware Requirements

As data does not expand, but is replaced, there is no requirement for more hardware. Mutable data does not require the high storage needs that immutable data does.

Compliance with GDPR

In accordance with EU laws and legislation, mutable data is highly compliant. Previous iterations of information are removed, and data is highly forgettable.

Challenges of Mutable Data

No Historical Context

Once that change is made in mutable data, there’s no easy access to the previous data other than going back to previous iterations or backups. When the mutable data is changed, all previous information is lost.

Resolution: Previous backups of data could be kept as a source of historical data. However, taking complete copies of databases presents storage issues and also is not in line with GDPR laws. Crypto-shedding of backups can resolve this, but it is an extra process which adds cost and time to all business functions.

The Requirement for Backups

Traditional mutable databases need to be backed up in order to maintain database history. This, depending on the business, may need weekly, daily, or even hourly backups. This not only becomes an IT management burden, but also adds time, cost, and complexity to a business function that could end up being redundant.

Resolution: While the need for backups remains, there are cloud storage options such as blockchain technology, where organizations can utilize complex structures that use free space on a range of external computers and systems to store data—minimizing the need for infrastructure investment.

Lack of Auditability and Business Analysis

Many industries face audits for data. Having no historical context can affect the auditability of the business, making it difficult or impossible to comply with business standards.

This has flow-on effects, with a loss of data that could be important for business analysis. With previous data simply disappearing, there is no opportunity for information to be used by artificial intelligence and assessed for useful information.

Resolution: Regular and accessible backups can be made to preserve business integrity.

Poorer Customer Service

If information is changed and previous data is abandoned, this can present customer service challenges. On a simple level, if someone had their name changed, but the proof of ID is in the different name, how can you confirm they are the same person? With previous name iterations removed, there is no way to go back and confirm these two customers are the same person.

On a larger, more important scale, healthcare databases cannot be mutable. Previous visits, appointments, diagnoses, and medications all need to be kept active and accessible.

Resolution: Some databases simply must be immutable. While this presents challenges of its own, for some industries such as healthcare, a mutable database could be catastrophic.

Future of Mutable Data Systems

The limitations of mutable data systems may mean that they will be slowly replaced with immutable data systems. The lack of continuity means that mutable data systems can simply not be used in a range of industries, such as healthcare and insurance. But in order to have a fully immutable system, there must be a series of conditions.

The big two challenges to immutable data systems are the extra space and hardware they require and their lack of easy compliance with GDPR.

In order to overcome this, databases in the future may be fully immutable, but use crypto-shedding to ensure that data privacy requirements are met. Then, the possibility of architecture that utilizes blockchain technology for storage can overcome the storage and hardware problems that ever-growing databases create.

Together, these solutions create a database with full historical integrity, and the security and protections needed under current legislation.