CM2: a Cloud Monetary Cost Model for Document-Based NoSQL Databases

In the modern digital world, vast amounts of information are stored in flexible, non-traditional formats known as document-oriented databases. Unlike the rigid, spreadsheet-like structures of older systems, these databases allow data to be organized in ways that mirror how applications actually use it, often grouping related information together in single, self-contained units. As companies move these systems to the cloud, where they are managed by large technology providers, the way data is organized stops being just a technical choice and becomes a financial one. Every time a computer reads a piece of data, writes a new one, or stores a file, the cloud provider charges a fee. These charges are based on the size of the data, the number of items accessed, and the complexity of the requests, creating a complex economic landscape where a small design decision can lead to significantly higher bills.

For years, experts designing these systems have relied on models that predict how fast a database will run or how much memory it will use. However, these traditional tools often ignore the actual money spent in the cloud. They might tell an engineer that a design is fast, but they cannot say if that speed comes at an unaffordable price. This gap leaves organizations guessing about their future costs, potentially leading to architectures that are efficient in performance but disastrous in budget. The challenge is that cloud pricing is not a single flat rate; it is a patchwork of fees for storage, for reading specific amounts of data, for writing updates, and for maintaining the indexes that help find information quickly. Without a way to translate technical design choices into a single dollar amount, comparing different database structures is like trying to compare the cost of two different cars when one price is in miles per gallon and the other is in engine horsepower.

To solve this, researchers Matteo Francia, Enrico Gallinucci, Matteo Golfarelli, and Alessandra Lumini from the University of Bologna developed a new tool called CM2. This is a cloud monetary cost model specifically designed for document-based NoSQL databases running in serverless environments. Instead of focusing on speed or technical complexity, CM2 acts as a financial calculator for database designers. It takes a proposed way of organizing data and a list of the questions the database will be asked, then calculates the exact monthly cost in dollars. The model does not guess; it breaks down the total expense into three distinct parts: the cost of storing the data and its indexes, the cost of reading the data, and the cost of writing or updating it. It accounts for the specific pricing policies of major cloud providers, such as how much they charge per gigabyte of storage or per byte of data transferred.

The researchers tested this model using a realistic scenario based on an online store, complete with customers, orders, products, and shipping details. They created different versions of how this store's data could be organized. In one version, they kept the data highly organized with minimal repetition, similar to a strict library catalog. In another, they duplicated information across different groups to make it faster to find, similar to keeping a copy of a map in every car. They then ran thousands of simulated queries against these different setups on a real cloud database service provided by Microsoft Azure. The goal was to see if their model could predict the actual bill the cloud provider would send.

The results were strikingly accurate. When the researchers compared the model's predictions to the real costs incurred by the cloud service, the difference was often less than two percent for the number of documents accessed and less than one percent for the number of index entries used. For the total storage size, the model was off by less than five percent. Even more importantly, the model successfully predicted the final monetary cost. In one test case, the model estimated a monthly cost of 0.70 dollars, while the actual cost was 0.73 dollars. In more complex scenarios involving millions of operations, the model consistently identified which database design would be the cheapest, correctly ranking the options even when the differences were subtle.

The study also revealed that the most efficient design depends entirely on how the system is used. A design that saves money on storage might end up costing a fortune if the application requires frequent, complex searches that force the system to read large amounts of data. Conversely, a design that repeats data to speed up searches might be the most economical choice if the system is read-heavy but rarely updated. The model showed that in some cases, a redundant design was cheaper because it reduced the number of expensive read operations, while in other cases, a leaner design won because it minimized the cost of writing updates. This proves that there is no single "best" way to build a database; the right choice is the one that aligns with the specific financial and operational patterns of the application.

By providing a unified way to measure cost, CM2 allows engineers to make informed decisions before they even build the system. It shifts the conversation from "will this work?" to "will this work within our budget?" The researchers demonstrated that ignoring the monetary dimension during the design phase can lead to architectures that are technically sound but financially unsustainable. Their work offers a practical framework for balancing performance and price, ensuring that the databases powering our digital world remain not only fast and flexible but also affordable.