{"id":{"repo_id":"passau-thes","oai_identifier":"oai:kobv.de-opus4-uni-passau:2067"},"canonical_url":"https://search.dev.ndltd.org/etd/passau-thes/oai:kobv.de-opus4-uni-passau:2067","repository":{"repo_id":"passau-thes","name":"Universität Passau","base_url":"https://opus4.kobv.de/opus4-uni-passau/oai"},"display":{"title":"Full-Stack Change Management for Database Systems","abstract":"Database systems are at the core of modern applications, providing essential services for storing, querying, and managing data. However, they do not remain static; they continuously evolve in response to external changes. Two primary external factors drive this evolution. On the one hand, database vendors release new versions of the database software, introducing new features, bug fixes, and security patches, resulting in the ongoing evolution of the database binary. On the other hand, developers modify the database schema, which defines the structure of the stored data, to accommodate new data structures required by client applications. This cumulative dissertation investigates the challenges of binary evolution and schema evolution in database systems. These two types of evolution represent disruptive changes at both ends of the stack of a database system from the perspective of externally driven changes. We examine various families of database systems, including relational, NoSQL document and key-value stores, as well as distributed variants. The state-of-the-art approach to address the binary evolution of a database system involves a restart: The database system is shut down, the binary replaced, and restarted. While this approach may be acceptable for full feature upgrades, it poses significant overhead when fixing bugs or patching vulnerabilities. Each restart leads to service interruptions and the loss of the in-memory state. Moreover, such downtimes are particularly problematic for cloud providers offering managed Database-as-a-Service. They cannot predict when a downtime is acceptable for customers, making it challenging to promptly patch critical vulnerabilities without disrupting service. To overcome these issues, we investigate live patching as a radically novel approach to binary evolution. Live patching allows code changes to be applied in-memory to the running application without necessitating a restart. We provide the first systematic evaluation of live patching for database systems. Using the relational database management system MariaDB as a case study, our comprehensive evaluation of single-instance, multi-threaded database systems demonstrates that live patching is a viable alternative to conventional restarts. We examine the interplay between various query workloads and live patching methods, analyzing their impact on transaction throughput and tail latencies. Additionally, we explore how the size of the in-memory state impacts live patching, using the in-memory key-value store Redis, and evaluate real-world patches applied to both MariaDB and Redis. Our findings provide insights into database-specific factors that influence live patching. These insights enable informed decisions about the latency overhead clients may experience during live patching. While single-instance database systems suffer complete service outages during restarts, database clusters are designed to mitigate such disruptions. When a node is taken offline, its workload can be redistributed to other nodes. The state-of-the-art approach to patch a database cluster is a rolling update, where each node is sequentially shut down, patched, and restarted, with other nodes taking over the workload of the node undergoing maintenance. Ideally, this patching process should (1) incur no downtime, (2) avoid noticeable performance degradations such as latency spikes, (3) maintain stable resource consumption, and (4) be executed promptly. Unfortunately, conventional rolling updates often fail to meet these goals. To address these limitations, we extend live patching to database clusters, demonstrating its feasibility and applicability using the distributed in-memory key-value store Redis Cluster as a case study. In a systematic evaluation, we demonstrate that our live patching approach satisfies all four aforementioned requirements, whereas conventional rolling updates do not. To enable seamless live patching, we develop and evaluate two patch distribution mechanisms. Both automate patch distribution across the cluster, with one prioritizing distribution speed and the other designed to accommodate the elasticity of the cluster. Finally, we offer general guidelines for integrating live patching and automatic patch distribution into distributed database systems, demonstrating their successful application using a primary-replica setup of the relational database management system PostgreSQL. To provide a holistic change management approach for database systems, it is crucial to address not only binary evolution but also the evolution of the database schema. The database schema defines the structure of stored data and serves as a contract between the database system and the applications that interact with it. When it evolves, it raises a critical question: Are the schema changes backward compatible, or do they introduce breaking changes for client applications? Unlike relational database management systems, NoSQL database systems do not follow a unified schema standard; instead, schemas are tailored to the specific data format being stored. For semi-structured data, JavaScript Object Notation (JSON) is widely used, with JSON Schema serving as the de-facto schema language for JSON data. To address the challenge of schema evolution for JSON Schema-based database schemas, we explore the concept of JSON Schema containment. JSON Schema containment can be used to decide whether the language defined by one JSON Schema is a subset of another. Our evaluation of existing JSON Schema containment checkers, applied to a diverse set of real-world schemas, reveals significant limitations. These tools often lack support for advanced JSON Schema features or yield inconsistent results, and therefore lack in consensus. Recognizing the absence of comprehensive schema management solutions for JSON-based NoSQL document stores that use JSON Schema for data validation, we propose a novel DevOps workflow implemented through our prototype tool, Josch. Josch is geared for MongoDB and integrates third-party JSON Schema extraction and containment checking solutions to assist developers and DevOps teams in efficiently managing schema changes. It enables the extraction of JSON Schemas from existing JSON documents when an explicit schema is absent and employs containment checking to ensure that schema changes remain backward compatible, thereby preventing breaking changes for client applications. In summary, our research provides a comprehensive approach to managing externally driven changes in database systems. By unifying our research on live patching for binary evolution with our solutions for schema evolution, we enable seamless updates to the database binary without disrupting services and protect client applications from breaking changes due to schema modifications.","abstract_html":"Database systems are at the core of modern applications, providing essential services for storing, querying, and managing data. However, they do not remain static; they continuously evolve in response to external changes. Two primary external factors drive this evolution. On the one hand, database vendors release new versions of the database software, introducing new features, bug fixes, and security patches, resulting in the ongoing evolution of the database binary. On the other hand, developers modify the database schema, which defines the structure of the stored data, to accommodate new data structures required by client applications. This cumulative dissertation investigates the challenges of binary evolution and schema evolution in database systems. These two types of evolution represent disruptive changes at both ends of the stack of a database system from the perspective of externally driven changes. We examine various families of database systems, including relational, NoSQL document and key-value stores, as well as distributed variants. The state-of-the-art approach to address the binary evolution of a database system involves a restart: The database system is shut down, the binary replaced, and restarted. While this approach may be acceptable for full feature upgrades, it poses significant overhead when fixing bugs or patching vulnerabilities. Each restart leads to service interruptions and the loss of the in-memory state. Moreover, such downtimes are particularly problematic for cloud providers offering managed Database-as-a-Service. They cannot predict when a downtime is acceptable for customers, making it challenging to promptly patch critical vulnerabilities without disrupting service. To overcome these issues, we investigate live patching as a radically novel approach to binary evolution. Live patching allows code changes to be applied in-memory to the running application without necessitating a restart. We provide the first systematic evaluation of live patching for database systems. Using the relational database management system MariaDB as a case study, our comprehensive evaluation of single-instance, multi-threaded database systems demonstrates that live patching is a viable alternative to conventional restarts. We examine the interplay between various query workloads and live patching methods, analyzing their impact on transaction throughput and tail latencies. Additionally, we explore how the size of the in-memory state impacts live patching, using the in-memory key-value store Redis, and evaluate real-world patches applied to both MariaDB and Redis. Our findings provide insights into database-specific factors that influence live patching. These insights enable informed decisions about the latency overhead clients may experience during live patching. While single-instance database systems suffer complete service outages during restarts, database clusters are designed to mitigate such disruptions. When a node is taken offline, its workload can be redistributed to other nodes. The state-of-the-art approach to patch a database cluster is a rolling update, where each node is sequentially shut down, patched, and restarted, with other nodes taking over the workload of the node undergoing maintenance. Ideally, this patching process should (1) incur no downtime, (2) avoid noticeable performance degradations such as latency spikes, (3) maintain stable resource consumption, and (4) be executed promptly. Unfortunately, conventional rolling updates often fail to meet these goals. To address these limitations, we extend live patching to database clusters, demonstrating its feasibility and applicability using the distributed in-memory key-value store Redis Cluster as a case study. In a systematic evaluation, we demonstrate that our live patching approach satisfies all four aforementioned requirements, whereas conventional rolling updates do not. To enable seamless live patching, we develop and evaluate two patch distribution mechanisms. Both automate patch distribution across the cluster, with one prioritizing distribution speed and the other designed to accommodate the elasticity of the cluster. Finally, we offer general guidelines for integrating live patching and automatic patch distribution into distributed database systems, demonstrating their successful application using a primary-replica setup of the relational database management system PostgreSQL. To provide a holistic change management approach for database systems, it is crucial to address not only binary evolution but also the evolution of the database schema. The database schema defines the structure of stored data and serves as a contract between the database system and the applications that interact with it. When it evolves, it raises a critical question: Are the schema changes backward compatible, or do they introduce breaking changes for client applications? Unlike relational database management systems, NoSQL database systems do not follow a unified schema standard; instead, schemas are tailored to the specific data format being stored. For semi-structured data, JavaScript Object Notation (JSON) is widely used, with JSON Schema serving as the de-facto schema language for JSON data. To address the challenge of schema evolution for JSON Schema-based database schemas, we explore the concept of JSON Schema containment. JSON Schema containment can be used to decide whether the language defined by one JSON Schema is a subset of another. Our evaluation of existing JSON Schema containment checkers, applied to a diverse set of real-world schemas, reveals significant limitations. These tools often lack support for advanced JSON Schema features or yield inconsistent results, and therefore lack in consensus. Recognizing the absence of comprehensive schema management solutions for JSON-based NoSQL document stores that use JSON Schema for data validation, we propose a novel DevOps workflow implemented through our prototype tool, Josch. Josch is geared for MongoDB and integrates third-party JSON Schema extraction and containment checking solutions to assist developers and DevOps teams in efficiently managing schema changes. It enables the extraction of JSON Schemas from existing JSON documents when an explicit schema is absent and employs containment checking to ensure that schema changes remain backward compatible, thereby preventing breaking changes for client applications. In summary, our research provides a comprehensive approach to managing externally driven changes in database systems. By unifying our research on live patching for binary evolution with our solutions for schema evolution, we enable seamless updates to the database binary without disrupting services and protect client applications from breaking changes due to schema modifications.","abstract_has_math":false,"creators":["Fruth, Michael"],"institution":"Universität Passau","degree_name":null,"degree_level":"thesis.doctoral","degree_discipline":null,"degree_department":null,"school":null,"contributors":["Scherzinger, Stefanie","Rabl, Tilmann"],"advisors":[],"committee_chairs":[],"committee_members":[],"year":2026,"date_issued":"2026-04-13","date_published":"2026-04-13","updated_at":"2026-07-24T03:45:12Z","subjects":["Database Management System","Live Patching","Distributed In-Memory Key-Value Stores"],"languages":[],"rights":["Standardbedingung laut Einverständniserklärung"],"rights_urls":[],"identifier_entries":[]},"links":{"outbound_url":"https://opus4.kobv.de/opus4-uni-passau/frontdoor/index/index/docId/2067","outbound_label":"Repository record","outbound_source":"source_url"},"metadata_groups":[{"id":"people","label":"People","entries":[{"key":"dc:contributor","label":"Contributor","values":["Scherzinger, Stefanie","Rabl, Tilmann"]},{"key":"dc:creator","label":"Author","values":["Fruth, Michael"]}]},{"id":"academic_context","label":"Academic Context","entries":[{"key":"dc:publisher","label":"Institution","values":["Universität Passau"]},{"key":"dc:type","label":"Dc Type","values":["doctoralThesis"]},{"key":"thesis:degree_level","label":"Degree Level","values":["thesis.doctoral"]},{"key":"thesis:institution_name","label":"Thesis Institution Name","values":["Universität Passau"]}]},{"id":"subjects_keywords","label":"Subjects and Keywords","entries":[{"key":"dc:subject","label":"Dc Subject","values":["Database Management System","Live Patching","Distributed In-Memory Key-Value Stores"]}]},{"id":"language_rights","label":"Language and Rights","entries":[{"key":"dc:rights","label":"Dc Rights","values":["Standardbedingung laut Einverständniserklärung"]}]},{"id":"additional","label":"Additional Metadata","entries":[{"key":"dc:description.abstract","label":"Abstract","values":["Database systems are at the core of modern applications, providing essential services for storing, querying, and managing data. However, they do not remain static; they continuously evolve in response to external changes. Two primary external factors drive this evolution. On the one hand, database vendors release new versions of the database software, introducing new features, bug fixes, and security patches, resulting in the ongoing evolution of the database binary. On the other hand, developers modify the database schema, which defines the structure of the stored data, to accommodate new data structures required by client applications. This cumulative dissertation investigates the challenges of binary evolution and schema evolution in database systems. These two types of evolution represent disruptive changes at both ends of the stack of a database system from the perspective of externally driven changes. We examine various families of database systems, including relational, NoSQL document and key-value stores, as well as distributed variants. The state-of-the-art approach to address the binary evolution of a database system involves a restart: The database system is shut down, the binary replaced, and restarted. While this approach may be acceptable for full feature upgrades, it poses significant overhead when fixing bugs or patching vulnerabilities. Each restart leads to service interruptions and the loss of the in-memory state. Moreover, such downtimes are particularly problematic for cloud providers offering managed Database-as-a-Service. They cannot predict when a downtime is acceptable for customers, making it challenging to promptly patch critical vulnerabilities without disrupting service. To overcome these issues, we investigate live patching as a radically novel approach to binary evolution. Live patching allows code changes to be applied in-memory to the running application without necessitating a restart. We provide the first systematic evaluation of live patching for database systems. Using the relational database management system MariaDB as a case study, our comprehensive evaluation of single-instance, multi-threaded database systems demonstrates that live patching is a viable alternative to conventional restarts. We examine the interplay between various query workloads and live patching methods, analyzing their impact on transaction throughput and tail latencies. Additionally, we explore how the size of the in-memory state impacts live patching, using the in-memory key-value store Redis, and evaluate real-world patches applied to both MariaDB and Redis. Our findings provide insights into database-specific factors that influence live patching. These insights enable informed decisions about the latency overhead clients may experience during live patching. While single-instance database systems suffer complete service outages during restarts, database clusters are designed to mitigate such disruptions. When a node is taken offline, its workload can be redistributed to other nodes. The state-of-the-art approach to patch a database cluster is a rolling update, where each node is sequentially shut down, patched, and restarted, with other nodes taking over the workload of the node undergoing maintenance. Ideally, this patching process should (1) incur no downtime, (2) avoid noticeable performance degradations such as latency spikes, (3) maintain stable resource consumption, and (4) be executed promptly. Unfortunately, conventional rolling updates often fail to meet these goals. To address these limitations, we extend live patching to database clusters, demonstrating its feasibility and applicability using the distributed in-memory key-value store Redis Cluster as a case study. In a systematic evaluation, we demonstrate that our live patching approach satisfies all four aforementioned requirements, whereas conventional rolling updates do not. To enable seamless live patching, we develop and evaluate two patch distribution mechanisms. Both automate patch distribution across the cluster, with one prioritizing distribution speed and the other designed to accommodate the elasticity of the cluster. Finally, we offer general guidelines for integrating live patching and automatic patch distribution into distributed database systems, demonstrating their successful application using a primary-replica setup of the relational database management system PostgreSQL. To provide a holistic change management approach for database systems, it is crucial to address not only binary evolution but also the evolution of the database schema. The database schema defines the structure of stored data and serves as a contract between the database system and the applications that interact with it. When it evolves, it raises a critical question: Are the schema changes backward compatible, or do they introduce breaking changes for client applications? Unlike relational database management systems, NoSQL database systems do not follow a unified schema standard; instead, schemas are tailored to the specific data format being stored. For semi-structured data, JavaScript Object Notation (JSON) is widely used, with JSON Schema serving as the de-facto schema language for JSON data. To address the challenge of schema evolution for JSON Schema-based database schemas, we explore the concept of JSON Schema containment. JSON Schema containment can be used to decide whether the language defined by one JSON Schema is a subset of another. Our evaluation of existing JSON Schema containment checkers, applied to a diverse set of real-world schemas, reveals significant limitations. These tools often lack support for advanced JSON Schema features or yield inconsistent results, and therefore lack in consensus. Recognizing the absence of comprehensive schema management solutions for JSON-based NoSQL document stores that use JSON Schema for data validation, we propose a novel DevOps workflow implemented through our prototype tool, Josch. Josch is geared for MongoDB and integrates third-party JSON Schema extraction and containment checking solutions to assist developers and DevOps teams in efficiently managing schema changes. It enables the extraction of JSON Schemas from existing JSON documents when an explicit schema is absent and employs containment checking to ensure that schema changes remain backward compatible, thereby preventing breaking changes for client applications. In summary, our research provides a comprehensive approach to managing externally driven changes in database systems. By unifying our research on live patching for binary evolution with our solutions for schema evolution, we enable seamless updates to the database binary without disrupting services and protect client applications from breaking changes due to schema modifications."]},{"key":"dc:format.medium","label":"Dc Format Medium","values":["application/pdf"]},{"key":"dc:title","label":"Title","values":["Full-Stack Change Management for Database Systems"]}]}],"canonical_facts":{"dc:contributor":["Scherzinger, Stefanie","Rabl, Tilmann"],"dc:creator":["Fruth, Michael"],"dc:description.abstract":["Database systems are at the core of modern applications, providing essential services for storing, querying, and managing data. However, they do not remain static; they continuously evolve in response to external changes. Two primary external factors drive this evolution. On the one hand, database vendors release new versions of the database software, introducing new features, bug fixes, and security patches, resulting in the ongoing evolution of the database binary. On the other hand, developers modify the database schema, which defines the structure of the stored data, to accommodate new data structures required by client applications. This cumulative dissertation investigates the challenges of binary evolution and schema evolution in database systems. These two types of evolution represent disruptive changes at both ends of the stack of a database system from the perspective of externally driven changes. We examine various families of database systems, including relational, NoSQL document and key-value stores, as well as distributed variants. The state-of-the-art approach to address the binary evolution of a database system involves a restart: The database system is shut down, the binary replaced, and restarted. While this approach may be acceptable for full feature upgrades, it poses significant overhead when fixing bugs or patching vulnerabilities. Each restart leads to service interruptions and the loss of the in-memory state. Moreover, such downtimes are particularly problematic for cloud providers offering managed Database-as-a-Service. They cannot predict when a downtime is acceptable for customers, making it challenging to promptly patch critical vulnerabilities without disrupting service. To overcome these issues, we investigate live patching as a radically novel approach to binary evolution. Live patching allows code changes to be applied in-memory to the running application without necessitating a restart. We provide the first systematic evaluation of live patching for database systems. Using the relational database management system MariaDB as a case study, our comprehensive evaluation of single-instance, multi-threaded database systems demonstrates that live patching is a viable alternative to conventional restarts. We examine the interplay between various query workloads and live patching methods, analyzing their impact on transaction throughput and tail latencies. Additionally, we explore how the size of the in-memory state impacts live patching, using the in-memory key-value store Redis, and evaluate real-world patches applied to both MariaDB and Redis. Our findings provide insights into database-specific factors that influence live patching. These insights enable informed decisions about the latency overhead clients may experience during live patching. While single-instance database systems suffer complete service outages during restarts, database clusters are designed to mitigate such disruptions. When a node is taken offline, its workload can be redistributed to other nodes. The state-of-the-art approach to patch a database cluster is a rolling update, where each node is sequentially shut down, patched, and restarted, with other nodes taking over the workload of the node undergoing maintenance. Ideally, this patching process should (1) incur no downtime, (2) avoid noticeable performance degradations such as latency spikes, (3) maintain stable resource consumption, and (4) be executed promptly. Unfortunately, conventional rolling updates often fail to meet these goals. To address these limitations, we extend live patching to database clusters, demonstrating its feasibility and applicability using the distributed in-memory key-value store Redis Cluster as a case study. In a systematic evaluation, we demonstrate that our live patching approach satisfies all four aforementioned requirements, whereas conventional rolling updates do not. To enable seamless live patching, we develop and evaluate two patch distribution mechanisms. Both automate patch distribution across the cluster, with one prioritizing distribution speed and the other designed to accommodate the elasticity of the cluster. Finally, we offer general guidelines for integrating live patching and automatic patch distribution into distributed database systems, demonstrating their successful application using a primary-replica setup of the relational database management system PostgreSQL. To provide a holistic change management approach for database systems, it is crucial to address not only binary evolution but also the evolution of the database schema. The database schema defines the structure of stored data and serves as a contract between the database system and the applications that interact with it. When it evolves, it raises a critical question: Are the schema changes backward compatible, or do they introduce breaking changes for client applications? Unlike relational database management systems, NoSQL database systems do not follow a unified schema standard; instead, schemas are tailored to the specific data format being stored. For semi-structured data, JavaScript Object Notation (JSON) is widely used, with JSON Schema serving as the de-facto schema language for JSON data. To address the challenge of schema evolution for JSON Schema-based database schemas, we explore the concept of JSON Schema containment. JSON Schema containment can be used to decide whether the language defined by one JSON Schema is a subset of another. Our evaluation of existing JSON Schema containment checkers, applied to a diverse set of real-world schemas, reveals significant limitations. These tools often lack support for advanced JSON Schema features or yield inconsistent results, and therefore lack in consensus. Recognizing the absence of comprehensive schema management solutions for JSON-based NoSQL document stores that use JSON Schema for data validation, we propose a novel DevOps workflow implemented through our prototype tool, Josch. Josch is geared for MongoDB and integrates third-party JSON Schema extraction and containment checking solutions to assist developers and DevOps teams in efficiently managing schema changes. It enables the extraction of JSON Schemas from existing JSON documents when an explicit schema is absent and employs containment checking to ensure that schema changes remain backward compatible, thereby preventing breaking changes for client applications. In summary, our research provides a comprehensive approach to managing externally driven changes in database systems. By unifying our research on live patching for binary evolution with our solutions for schema evolution, we enable seamless updates to the database binary without disrupting services and protect client applications from breaking changes due to schema modifications."],"dc:format.medium":["application/pdf"],"dc:publisher":["Universität Passau"],"dc:rights":["Standardbedingung laut Einverständniserklärung"],"dc:subject":["Database Management System","Live Patching","Distributed In-Memory Key-Value Stores"],"dc:title":["Full-Stack Change Management for Database Systems"],"dc:type":["doctoralThesis"],"thesis:degree_level":["thesis.doctoral"],"thesis:institution_name":["Universität Passau"]},"updated_at":"2026-07-24T03:45:12Z"}