Empirical Performance and Operational Analysis of Monolithic and Distributed Database Architectures in Kubernetes Environments

Abstract

This study presents a systematic empirical evaluation of monolithic and distributed database architectures deployed in Kubernetes environments. As containerized and cloud-native infrastructures become increasingly prevalent, understanding the performance implications of running stateful data systems under orchestration platforms has become critical. We evaluate five widely used database systems—PostgreSQL, MySQL, MongoDB, Redis, and Cassandra—using standardized workload generation frameworks, including pgbench, sysbench, YCSB, redis-benchmark, and cassandra-stress. Controlled experiments were conducted across varying concurrency levels and workload types to measure throughput, latency, and scalability in both single-node and distributed deployments. Redis achieves a maximum throughput of 4.2 million operations per second with sub-millisecond latency. In contrast, Cassandra delivers 214,743 distributed read operations per second at ONE consistency, approaching Redis’s non-pipelined baseline throughput (257,732–262,467 ops/sec) within a Kubernetes cluster. The write throughput of Cassandra decreases by 45.2% when the consistency level is elevated to QUORUM, accompanied by an elevenfold increase in run-to-run variability (CV from 7.1% to 84.7%), indicating that the consistency level is the primary performance determinant in distributed systems. PostgreSQL experiences a 72% decrease in write throughput in Kubernetes (74,072 → 20,805 TPS). In contrast, MySQL PXC anomalously attains a 37.3% increase in write throughput in Kubernetes compared to its monolithic deployment—the sole reversal noted among the five systems. These findings underscore a critical trade-off between vertical efficiency and horizontal scalability, illustrating that hybrid database architecture can be an effective solution for contemporary cloud-native applications compared to either paradigm independently.

1. Introduction

The rapid adoption of containerization and cloud-native computing has fundamentally altered the deployment and operation of contemporary software systems [1]. As a result, understanding the performance implications of these environments has become a critical concern in cloud-native systems engineering [2]. Container orchestration technologies, particularly Kubernetes, have emerged as the standard for managing distributed applications, offering automated deployment, horizontal scalability, fault tolerance, and efficient resource utilization [3]. However, these same characteristics introduce architectural complexities that can significantly influence database performance [4].

At the same time, these advancements have accelerated the transition toward microservice-based architectures designed to support highly dynamic and scalable workloads [5,6]. Despite these benefits, deploying stateful systems such as databases within container orchestration environments remains a significant challenge. Traditional database management systems are designed for stable, tightly coupled infrastructures. In contrast, Kubernetes introduces dynamic scheduling, container abstraction, distributed networking, and externalized storage layers, all of which can affect runtime behavior. In addition, factors such as network configuration, storage backend latency, and scheduling policies further influence the performance of stateful workloads independently of the database engine.

Database systems are pivotal in contemporary application architectures, and their design directly affects system performance, scalability, and operational complexity. Database architectures can be classified into monolithic and distributed systems. Monolithic databases function as single-node systems in which storage, query processing, and transaction management are tightly integrated. These systems generally rely on vertical scaling and are designed for low-latency transactional workloads that require robust consistency guarantees. Conversely, distributed databases comprise multiple nodes and distribute data through mechanisms such as sharding and replication. This enables horizontal scalability and enhances fault tolerance, yet incurs coordination overhead and escalates system complexity.

In this context, NoSQL databases have emerged as a prominent class of distributed data management systems designed to address the scalability and flexibility limitations of traditional relational models. NoSQL systems, such as wide-column and key–value stores, prioritize horizontal scalability, high availability, and schema flexibility, often adopting relaxed consistency models in accordance with the CAP theorem.

The rise of Kubernetes as a standard platform for cloud-native infrastructure has heightened interest in running both monolithic and distributed database systems within containerized environments. Kubernetes offers technologies such as StatefulSets, persistent volumes, and operators that facilitate the orchestration of stateful workloads, ensuring that storage persistence and network identity are maintained. The interplay between database architecture and orchestration infrastructure presents novel performance and operational challenges that remain poorly understood.

Current research has investigated database performance in both standalone and containerized environments, whereas few studies have assessed databases in Kubernetes. Nonetheless, these contributions remain disjointed—comparative analyses of relational and NoSQL systems generally occur outside orchestration contexts and fail to account for container networking, persistent volume access, and scheduler interference. At the same time, Kubernetes-focused research is typically confined to a single database system. No prior work provides a systematic, multi-system empirical evaluation of monolithic versus distributed architectures under controlled Kubernetes conditions. This gap motivates the present study.

This study presents a controlled empirical assessment of five prevalent database systems—PostgreSQL, MySQL, MongoDB, Redis, and Cassandra—encompassing both relational and NoSQL frameworks to address this gap. The assessment employs standardized workload generation frameworks, such as pgbench, sysbench, YCSB, redis-benchmark, and cassandra-stress, to quantify throughput, latency, and scalability across diverse workload types and concurrency levels. Experiments are performed in both single-node (monolithic) and distributed Kubernetes deployments to facilitate systematic comparison under uniform conditions.

This study aims to quantify performance disparities among database systems and to examine the architectural trade-offs between vertically scaled monolithic databases and horizontally scalable distributed databases within Kubernetes environments. Understanding these trade-offs is crucial for architecting database infrastructure that balances performance efficiency, scalability, and operational complexity in cloud-native applications.

This study addresses the following three research questions, deliberately structured to progress from measurement to explanation to practical guidance:

RQ1. How do monolithic and distributed database architectures differ in throughput and latency within Kubernetes environments across diverse workloads and concurrency levels?

RQ2. Which database architecture offers superior scalability and workload suitability for write-intensive transactional versus read-intensive distributed workloads?

RQ3. What operational trade-offs emerge when deploying monolithic versus distributed databases in Kubernetes, with respect to scalability, resource management, and system resilience?

These questions are interconnected: RQ1 establishes the empirical baseline, RQ2 interprets scalability and workload fit, and RQ3 contextualizes both within practical cloud-native operational constraints.

This study’s primary contributions are as follows:

• Systematic empirical assessment: A comparative analysis of five prevalent database systems in both monolithic and Kubernetes-based distributed environments under uniform workloads;
• Examination of architectural trade-offs: A study of the impact of database architecture on throughput, latency, and scalability across various workload profiles;
• Operational insights for cloud-native implementations: Practical guidance for selecting effective database architectures in Kubernetes environments, covering cases where monolithic, distributed, or hybrid approaches are optimal.

The subsequent sections of this paper are structured as follows. Section 2 examines pertinent literature on cloud-native databases and their performance evaluation. Section 3 describes the experimental methodology. Section 4 presents the experimental results. Section 5 provides extended results and the complete dataset. Section 6 examines the findings and their implications. Section 7 closes the work and examines avenues for future research.

2. Related Work

This study encompasses two interrelated domains: cloud-native database deployment and database performance assessment. Recent survey research reveals that cloud-native computing has matured into a well-established research domain focused on orchestration, elasticity, observability, and service reliability, with Kubernetes emerging as the preeminent execution platform for contemporary distributed systems [1]. Simultaneously, research on cloud-native databases indicates a distinct architectural transition towards decoupled storage and compute layers, elastic scalability, and service-oriented control planes, rather than merely transferring conventional database systems into containerized environments without reconfiguration [2]. From an infrastructural standpoint, previous research on Kubernetes scheduling and cloud-native security indicates that orchestration policies, cluster networking, and resilience measures can profoundly affect runtime behavior, especially for stateful and latency-sensitive services [3,4]. These findings emphasize that database performance in Kubernetes systems cannot be assessed in isolation from the underlying orchestration architecture.

A subsequent line of inquiry investigates the shift from monolithic systems to microservices and cloud-native architectures. Nascimento et al. demonstrate that cloud-native platforms enhance scalability, availability, and operational flexibility, while concurrently introducing more complexity in deployment and system management [5]. Toomwong and Viyanon assert that containerized microservice architectures, implemented with Docker and Kubernetes, can improve throughput and reduce response times under scalable workloads [6]. Bjørndal et al. underscore the importance of comprehensive performance assessment throughout the transition from monolithic to microservice architectures, asserting that latency, throughput, scalability, and resource consumption should be evaluated collectively rather than in isolation [7]. Nonetheless, these studies predominantly focus on application-level architectures and provide limited insight into the behavior of database systems operating under stateful workloads in orchestrated settings.

A third area of research addresses the methodological issues associated with database performance evaluation. Taipalus highlights persistent problems in DBMS benchmarking studies, such as restricted reproducibility, impractical workloads, and inadequate documentation of experimental setups [8]. Wang et al. illustrate that performance outcomes are acutely sensitive to experimental settings, including concurrency levels, dataset size, workload composition, and system architecture, indicating that ostensibly similar experiments can provide markedly divergent conclusions [9]. These findings are especially pertinent to comparative evaluations of relational and NoSQL systems, as observed performance discrepancies may partly stem from experimental design decisions rather than inherent architectural characteristics. This corpus of work underscores the necessity for carefully controlled, thoroughly recorded, and reproducible experimental techniques.

A significant amount of research has concentrated on direct performance comparisons between relational and NoSQL database systems. Difallah et al. show that PostgreSQL often outperforms MySQL in read-intensive scenarios, whereas insert performance varies with workload characteristics and concurrency levels [10]. Antas et al. demonstrate that SQL and NoSQL systems exhibit different performance trade-offs across dimensions such as query execution time, memory consumption, CPU usage, and storage efficiency [11]. Győrödi et al. similarly demonstrate that the kind of workload and data representation substantially influence CRUD performance in a comparison between MongoDB and document-oriented MySQL [12]. Cooper et al. augment these findings by demonstrating that performance rankings among document databases vary significantly with workload composition, dataset size, and concurrency levels [13]. These studies together affirm that no singular database technology is universally superior; instead, performance is significantly influenced by workload factors and system architecture.

Numerous studies have performed targeted comparisons of particular database systems. Makris et al. compare MongoDB and PostgreSQL for spatio-temporal workloads, showing that PostgreSQL generally performs better for complex analytical queries, while MongoDB can provide advantages in certain specialized scenarios [14]. Alzaidi and Vágner examine Redis and MongoDB within application-specific frameworks, illustrating that database performance is significantly influenced by data modeling choices and application-level query patterns, rather than solely by raw benchmark results [15]. Cassandra has near-linear scalability in read throughput as the number of nodes increases for key-based access patterns [16]. These findings validate a workload dependency: NoSQL systems are superior for high-concurrency key-value or document access and extensive distributed reads, whereas relational systems maintain advantages for intricate queries, joins, and robust consistency. A summary table for NoSQL database characteristics is shown in Table 1:

Table 1. Summary of NoSQL database system performance characteristics.

Database	Paradigm	Throughput Profile	Latency Profile	Excels at	Weaker for
MongoDB	Document store	Moderate (thousands ops/sec, low concurrency; scales with threads	Moderate (ms range)	Flexible schema, document retrieval	Complex joins, high concurrency writes
Redis	In-memory key-value	Extremely high (100k–4M+ ops/sec)	Sub-millisecond	Caching, session data, counters	Persistence, large datasets
Cassandra	Wide column distributed	Very high (150k–220k ops/sec at ONE consistency)	Low to moderate	Distributed reads, HA writes, time-series	Complex queries, stronger consistency
MongoDB (distributed)	Document store (replica set)	Moderate; limited by coordination overhead	Higher than monolithic	Read scaling with secondary offloading	Write-heavy, strict consistency

Research on database systems implemented in Kubernetes environments remains relatively scarce but is gradually increasing. Sharma et al. evaluate PostgreSQL/PostGIS workloads in Kubernetes and show that clustered deployments can improve performance for certain resource-intensive queries under appropriate configurations [17]. Cardas et al. analyze SQL-on-Hadoop systems deployed on Kubernetes and conclude that, while Kubernetes provides a viable platform for scalable data processing, performance depends heavily on how systems adapt to the orchestration environment [18]. Gkamas et al. examine distributed database strategies in containerized industrial IoT scenarios, demonstrating that horizontal scaling can improve throughput but may also increase latency due to coordination overhead [19]. Taken together, these studies highlight a consistent finding: when databases are containerized or distributed, infrastructure characteristics such as networking, storage, and orchestration mechanisms become tightly coupled with database performance.

Beyond performance metrics, recent work has also explored the operational aspects of running stateful systems in Kubernetes. Lee et al. propose a persistence framework for in-memory databases that uses container checkpointing, demonstrating that recovery time can be reduced compared to traditional snapshot-based approaches [20]. Dakić et al. develop methodologies for evaluating Kubernetes container network interfaces and demonstrate that network configuration can significantly affect latency and overall system performance [21,22]. These findings are particularly relevant for distributed databases, where performance is often sensitive to network latency, replication overhead, and coordination costs. They further reinforce the view that database performance in Kubernetes environments is inherently a systems-level concern rather than purely a property of the database engine.

Recent research has reestablished the connection between database performance measurement and contemporary service architectures. Pantelić et al. demonstrate that concurrency levels and the equilibrium of read/write workloads substantially affect the comparative performance of SQL and NoSQL systems in microservice contexts [23]. The assertion that architectural design profoundly influences the balance between transactional and analytical performance is well-established in the literature. Kemper and Neumann illustrate that within a singular system, the conflict between OLTP and OLAP execution pathways imposes stringent architectural limitations that cannot be mitigated solely through configuration [24]. This notion easily applies to distributed deployment: when a database intended for one execution paradigm is situated in an environment optimized for another, performance costs are structural rather than incidental. Studies in e-commerce contexts demonstrate that relational databases such as PostgreSQL can outperform document-oriented databases for read-intensive queries requiring complex filtering and multi-attribute lookups, depending on schema design and access patterns [25,26,27]. Although these studies align with the workload-driven perspective presented in this paper, they fail to provide a comprehensive assessment of the various database architectures used in Kubernetes environments, nor do they investigate both performance and operational trade-offs in a controlled experimental context.

Benchmark studies in relational contexts typically demonstrate superior read and transaction performance with PostgreSQL, particularly for selective queries and application-oriented operations. Still, MySQL and Oracle may remain competitive under specific access patterns or implementation strategies. Salunke and Ouda’s benchmark demonstrated that PostgreSQL significantly outperformed MySQL in various select-heavy workloads. In contrast, Choina and Skublewska-Paszkowska indicated that the use of ORM and workload size can substantially alter the comparative performance of MySQL, PostgreSQL, and Oracle in practical applications [25,26]. Analogous evaluations in web and e-commerce environments characterize performance not as an inherent attribute of a DBMS, but rather as a function of schema design, query composition, middleware, and deployment circumstances [27,28]. Liyanage et al. argue that conventional benchmarks exclude a crucial real-world factor—fluctuating value lengths—which might cause performance discrepancies among storage engines [29]. Topcu et al. assess NoSQL database performance in cloud computing environments, demonstrating that the trade-offs between scalability and consistency differ significantly among system types and workload configurations [30]. The choice between SQL and NoSQL databases largely depends on application needs, particularly scalability, consistency, and the characteristics of the data being handled [31]. A rapidly developing area of investigation advances this concept, transitioning from static benchmark comparisons to adaptive and learning methodologies: Li et al. present a cost model that derives query performance characteristics from data attributes [32], whereas Lehmann et al. investigate the reliability limits of these learned optimizers under diverse conditions [33], indicating a need for more dynamic performance evaluation frameworks in future benchmark design.

Collectively, these recent benchmark studies emphasize a consistent conclusion: database performance is not an inherent attribute of a system in isolation, but rather an emergent quality arising from the interplay between the database engine, the workload it handles, the access patterns it accommodates, and the deployment environment in which it functions. As established methodologically by Taipalus [9] and Wang et al. [10], and empirically corroborated by the relational comparisons of Salunke and Ouda [25], Choina and Skublewska-Paszkowska [26], and Zapata [27], even rigorously controlled benchmarks can produce significantly divergent conclusions based on dataset characteristics, concurrency levels, and application-layer configurations. Khan et al. [31] synthesize this evidence across SQL and NoSQL paradigms, concluding that workload type and consistency requirements are the primary determinants of relative system performance. This body of work establishes the methodological and comparative framework for the current study, which is enhanced by concurrently assessing numerous systems, with the added performance metric of Kubernetes orchestration.

3. Materials and Methods

This study assesses the performance attributes of monolithic and distributed database architectures implemented in Kubernetes environments through a controlled experimental investigation. The methodology aims to ensure reproducibility and comparability among database systems and deployment models. Performance is evaluated using standardized workload-generating tools in controlled environments to measure throughput, latency, and scalability across various scenarios.

The experimental design contrasts single-node (monolithic) deployments with distributed deployments conducted within a Kubernetes cluster. The primary goal is to isolate the effects of deployment design while ensuring uniformity across hardware resources, operating system configurations, and workload characteristics.

3.1. Experimental Framework

The experimental assessment was performed in two separate settings: a monolithic database environment and a distributed Kubernetes cluster. These settings were designed to represent deployment scenarios representative of contemporary cloud-native application architectures.

The monolithic setup comprised a singular high-performance workstation that hosted independent database instances. The system had a 13th-generation Intel Core i7-13700 processor (Intel Corporation, Santa Clara, CA, USA), 64 GB of DDR5 RAM, and a 1 TB NVMe SSD. A Realtek RTL8125 2.5 GbE controller (Realtek Semiconductor Corp., Hsinchu, Taiwan) facilitated network access. This design exemplifies a standard single-node deployment tailored for low-latency transactional applications.

The distributed environment was configured as a Kubernetes cluster hosted on virtualized infrastructure administered via VMware vSphere Client version 8.0.1 (Broadcom Inc., Palo Alto, CA, USA). The cluster had three nodes, each equipped with an Intel Xeon Gold 6326 processor, 24 virtual CPUs, and 64 GB of DDR4 RAM. HPE Nimble Fiber Channel storage (Hewlett Packard Enterprise, Spring, TX, USA) offered 1 TB of persistent storage, presented as block storage volumes to guarantee low-latency access appropriate for database workloads. Cluster networking was implemented via VMXNET3 virtual network interfaces with a capacity of 10 Gbps. All nodes were connected in a single virtualized network environment, reducing external network unpredictability while maintaining inter-node communication overhead. The cluster was deployed utilizing Kubernetes version 1.30, with containerd serving as the container runtime. The architecture is shown in Figure 1.

Figure 1. Architecture of the experimental framework. Left: monolithic single-node deployment. Right: distributed Kubernetes cluster (on VMware vSphere) with shared Fiber Channel persistent storage.

Kubernetes was chosen over Docker Compose for multiple reasons. Kubernetes offers StatefulSets, PersistentVolumeClaims, and headless Services were essential for production-like stateful clusters [3]. Docker Compose lacks functionality for these at a cluster scale. Second, Kubernetes is the definitive standard for cloud-native applications, making the outcomes immediately relevant to deployment decisions. Third, previous research indicates that Kubernetes networking, scheduling, and storage abstractions impose overhead distinct from Docker’s paradigm [21,22], and our analysis isolates this overhead.

Both environments used Ubuntu Server 24.04.2 LTS (Noble Numbat) to ensure consistent operating system performance across deployments. This homogeneity reduces variability caused by system-level discrepancies and enables reproducible experimentation.

3.2. Assessed Database Systems

The experimental assessment encompasses a selection of commonly used database administration solutions that exemplify both relational and NoSQL paradigms, as well as various architectural methodologies for data management. These systems were chosen to represent a diverse array of database technologies frequently utilized in cloud-native and microservice-oriented applications.

The systems under evaluation comprise:

• Relational databases: PostgreSQL version 17.5 and MySQL version 8.0.41;
• Document-oriented database: MongoDB version 7.0.5;
• In-memory key-value database: Redis 8.2.0;
• Distributed wide-column database: Cassandra version 4.0.3.

PostgreSQL, MySQL, MongoDB, and Redis were assessed in monolithic (single-node) setups. PostgreSQL, MySQL, MongoDB, and Cassandra were assessed in distributed setups within the Kubernetes cluster.

Redis was assessed solely in a monolithic setup, as it is fundamentally engineered as an in-memory datastore suited for vertical scaling and minimal latency operations. In contrast, Cassandra was assessed solely in a distributed configuration, as its architecture is fundamentally intended for multi-node deployment and does not exemplify a significant monolithic use case. These selections signify the designated operational functions of the respective systems.

3.3. Kubernetes Deployment Configuration

Distributed database deployments were executed via containerized instances orchestrated by Kubernetes. Stateful workloads were implemented using Kubernetes-native methods that support persistent storage and consistent network identities.

Persistent storage was implemented using Kubernetes PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources, ensuring data retention independent of container lifecycle events. This design enables resistance to pod restarts and rescheduling.

Kubernetes StatefulSets were used to manage database instances that require persistent identities and ordered deployment. StatefulSets offer predictable naming, stable network endpoints, and durable storage associations, which are crucial for distributed database systems that depend on consistent cluster membership and node identity.

Supplementary Kubernetes resources, such as Services, ConfigMaps, and Secrets, were used to manage network connections, configuration parameters, and sensitive credentials. These components ensured uniform configuration across cluster nodes and reliable connectivity between database instances and workload-generation clients.

Distributed database systems were implemented utilizing their inherent clustering processes. PostgreSQL and MySQL were set up with primary-replica architectures using asynchronous replication; MongoDB was implemented as a replica set without sharding; and Cassandra functioned as a multi-node cluster with a replication factor of 3 and configurable consistency levels, representing a typical production setup for a three-node deployment. These configurations exemplify frequently employed production deployment methods.

Database performance in distributed contexts is significantly influenced by configuration options, including replication techniques, consistency levels, storage backends, and network configurations. This study selected configurations that represent frequently used production settings to ensure practical relevance. Nonetheless, other combinations may produce varying performance attributes. Subsequent research should investigate a broader configuration space to more accurately assess each system’s sensitivity to deployment and tuning settings.

3.4. Workload Generation and Workload Design

The performance of the database was assessed using recognized workload-generation tools that replicate real-world application behavior across several database paradigms:

• PostgreSQL was assessed using pgbench, which simulates transactional workloads in accordance with the TPC-B benchmark;
• MySQL was assessed using sysbench, which supports variable transactional workloads with adjustable read/write ratios;
• MongoDB was assessed using the Yahoo! Cloud Serving Benchmark (YCSB), which provides well-defined workload profiles that reflect prevalent cloud application trends;
• Redis was assessed using redis-benchmark, which produces high-concurrency key-value operations;
• Cassandra was assessed utilizing cassandra-stress, which enables adjustable distributed read and write workloads.

Custom workload scripts were developed for PostgreSQL: (1) write-test.sql—randomized INSERTs and UPDATEs; (2) read-test.sql—randomized point-select queries; (3) oltp-test.sql—mixed reads, updates, and transaction logging. For MySQL, sysbench provided five standardized profiles: oltp_read_only (16 SELECT/txn), oltp_point_select (single-row lookups), oltp_write_only (INSERT/UPDATE/DELETE), oltp_update_index (indexed-column updates), and oltp_read_write (mixed OLTP). For MongoDB, YCSB workloads A (50/50 read-update), B (95/5), C (100% read), and F (read–modify–write) were applied. For Cassandra, cassandra-stress was configured at consistency levels ONE and QUORUM for read, write, and mixed workloads.

For dataset sizes, we used PostgreSQL at pgbench scaling factors 500 and 1000 (~7.2 GB and ~14.4 GB); MySQL at 100 and 200 tables; MongoDB at 5 million and 10 million records; Cassandra at 5 million and 10 million partitions; Redis at 100,000 operations (256-byte payload) and 10 million operations (1024-byte, pipelined). Table 2 shows the workload parameter matrix used for all evaluated database systems:

Table 2. Workload parameter matrix for all evaluated database systems.

Database	Deployment	Workload Types	Dataset Scale	Concurrency	Tool
PostgreSQL	Monolithic	Write, Read, OLTP-mixed	Scale 500 & 1000	72c/24t	pgbench
PostgreSQL	Kubernetes	Write, Read, OLTP-mixed	Scale 500 & 1000	64c/20t	pgbench
MySQL	Monolithic	5 OLTP workloads	100 & 200 tables	24–48t	sysbench
MySQL	Kubernetes	5 OLTP workloads	100 & 200 tables	64–72t	sysbench
MongoDB	Monolithic	Workloads A, B, C, F	5M & 10M records	64 & 200t	YCSB
MongoDB	Kubernetes	Workloads A, B, C, F	5M/10M records	64 & 200t	YCSB
Redis	Monolithic	SET, GET + 9 op types	100K & 10M ops	50 & 200t	redis-benchmark
Cassandra	Kubernetes	Write ONE/QUO, Read ONE, Mixed QUO	5M & 10M partitions	200t	cassandra-stress

Workloads were formulated to exemplify various access patterns, encompassing read-intensive, write-intensive, and mixed transactional workloads. The concurrency levels were adjusted by varying the number of client connections and worker threads. In distributed deployments, concurrency levels were deliberately adjusted—specifically reduced for PostgreSQL (64c/20t vs. 72c/24t monolithic) and increased for MySQL (64–72t vs. 24–48t monolithic)—to reflect realistic multi-client cluster workloads and the differing saturation points of each deployment configuration, rather than applying identical parameters across architectures. This modification illustrates authentic deployment behavior, in which various designs achieve optimal performance at distinct concurrency levels. Imposing uniform concurrency in both monolithic and distributed contexts would create unnecessary limitations and could distort the true operational capacity of any system. Consequently, concurrency was adjusted to align with the saturation points for each configuration, ensuring that performance comparisons reflect practical deployment scenarios rather than consistent yet artificial testing criteria.

3.5. Performance Metrics

The experimental assessment focuses on throughput and latency as primary performance metrics, consistent with established database benchmarking methodology [9,10]. Table 3 formally defines all metrics used.

Table 3. Performance metrics: definitions and units.

Metric	Definition	Unit	Tools
Throughput	Operations completed per unit time	TPS or ops/sec	All
Average latency	Mean elapsed time per operation	ms or µs	All
Latency standard deviation	StdDev of per-operation elapsed time	ms	pgbench, sysbench
p95 latency	Latency below which 95% of ops complete	ms	All
p99 latency	Tail latency—99th percentile	ms	redis-benchmark, cassandra-stress, YCSB
CPU utilization	CPU capacity used	%	System monitoring
Memory utilization	RAM consumed by the database process	GB	System monitoring

These metrics collectively provide a comprehensive perspective on system performance across both monolithic and distributed deployment modes.

3.6. Methodology of Experimentation

The experimental technique adhered to a systematic, replicable methodology to ensure uniform comparability across database systems and deployment environments.

Each database system was assessed under controlled workload parameters, including dataset size, concurrency level, and execution time. Where relevant, equivalent workload metrics were employed across deployment strategies to facilitate meaningful comparison.

Each run lasted between 300 and 600 s, depending on the tool used. A warm-up period was observed in all runs. Each evaluation configuration was completed at least three distinct times; MySQL Kubernetes runs utilized two baseline runs for each table-scale configuration (resulting in four K8s runs per workload type). The values shown in Section 4 are the means across repetitions; standard deviations and interval-level statistics are detailed in the tables throughout the paper.

The experimental design, constrained to a cluster size of three nodes, effectively illustrates essential attributes of distributed database functionality, such as replication, partitioning, and inter-node coordination, which scale proportionately in bigger implementations. Standardized benchmarking techniques facilitate reproducibility and controlled comparisons among systems; nonetheless, it is crucial to recognize that these workloads exemplify simulated access patterns. While they resemble typical database operations, they fail to capture the intricacies of real-world applications, where database interactions are frequently integrated into multi-tier architectures, involve diverse query patterns, and are affected by application logic, caching mechanisms, and network fluctuations. Thus, the findings of this study should be regarded as indicative of essential system behavior under regulated conditions, rather than precise forecasts of performance in operational settings.

4. Results

This section presents the findings of the experimental assessment comparing monolithic and distributed database implementations in Kubernetes environments. The research emphasizes throughput and latency as the principal performance metrics, supplemented by assessments of system resource utilization. The aim is to deliver a systematic and comprehensible assessment of database performance across various architectures and workload categories.

Due to the inherent uncertainty in distributed systems, the results are accompanied by a comprehensive statistical analysis that includes variability metrics, confidence intervals, and trend evaluations. This level of information aims to ensure transparency and reproducibility, and to document performance attributes that may be obscured by mean values alone, especially in systems exhibiting significant fluctuations or non-deterministic behavior.

Results are presented for each database system, followed by a comparative summary highlighting overarching performance trends and architectural trade-offs.

4.1. PostgreSQL

PostgreSQL was assessed as a prototypical relational database system tailored for transactional workloads. The results provide a foundation for comprehending the behavior of classic OLTP systems across various deployment methods.

4.1.1. PostgreSQL Monolithic and Distributed Results

The performance of PostgreSQL in monolithic and distributed systems is shown in Table 4:

Table 4. PostgreSQL performance in monolithic and Kubernetes deployments. Mean +/− StdDev from 60 ten-second intervals per run (n = 2 runs per configuration). CV% = coefficient of variation.

Deployment	Scale	Workload	Clients/Threads	TPS	Avg Lat (ms)	Lat StdDev (ms)	CV% (TPS)	Stability
Monolithic	500	Write	72/24	74,072	0.969	1.160	19.8%	MEDIUM
Monolithic	500	Read	72/24	345,459	0.208	0.081	3.0%	HIGH
Monolithic	500	OLTP-mix	72/24	78,186	0.918	1.477	7.8%	HIGH
Monolithic	1000	Write	72/24	77,833	0.922	1.586	9.0%	HIGH
Monolithic	1000	Read	72/24	346,352	0.207	0.081	2.8%	HIGH
Monolithic	1000	OLTP-mix	72/24	78,114	0.919	1.361	8.5%	HIGH
Kubernetes	500	Write	64/20	20,805	3.059	6.666	40.9%	LOW
Kubernetes	500	Read	64/20	293,758	0.195	0.362	3.3%	HIGH
Kubernetes	500	OLTP-mix	64/20	28,398–32,695	1.943–2.238	2.163–3.115	33.5%	LOW
Kubernetes	1000	Write	64/20	25,063	2.537	4.942	41.8%	LOW
Kubernetes	1000	Read	64/20	294,071	0.194	0.268	3.2%	HIGH
Kubernetes	1000	OLTP-mix	64/20	30,226–33,884	1.874–2.102	1.989–2.511	33.8%	LOW

Kubernetes write workloads suffer a 66–72% throughput reduction compared to monolithic, with latency standard deviation inflating from 1.160 ms to 6.666 ms. Read workloads degrade by only 15% and maintain identical stability (CV ~3%), demonstrating that Kubernetes overhead is specifically a write-path phenomenon. The 10-s interval data show K8s write TPS swinging between 12,000 and 38,000 within individual runs—variability invisible in mean values alone.

The statistical analysis of scale sensitivity across the two dataset sizes is presented in Table 5:

Table 5. PostgreSQL performance change between pgbench scale 500 (~7.2 GB) and scale 1000 (~14.4 GB). All |Δ| < 5% in the monolith confirms scale invariance within the tested range.

Deployment	Workload	TPS Scale 500	TPS Scale 1000	TPS Δ%	Lat Δ%	Scale Stability
Monolithic	Write	74,072	77,833	+5.1%	−4.9%	Stable
Monolithic	Read	345,459	346,352	+0.3%	−0.5%	Stable
Monolithic	OLTP-mix	78,186	78,114	−0.1%	+0.1%	Stable
Kubernetes	Write	20,805	25,063	+18.6%	−17.1%	Moderate
Kubernetes	Read	293,758	294,071	+0.1%	−0.5%	Stable
Kubernetes	OLTP-mix	30,420	30,226	−0.6%	−7.4%	Stable

Our analysis illustrates that PostgreSQL performance is largely scale-invariant across the two evaluated dataset sizes in the monolithic deployment, with all throughput and latency variations remaining under 5.1% between scaling factors 500 and 1000.

4.1.2. PostgreSQL Analysis

Analysis of results from the two dataset sizes examined indicates that, for the monolithic PostgreSQL deployment, the TPS variance between scales is under 5.1%, and latency discrepancies are comparably minimal. This stability is due to PostgreSQL’s buffer pool and NVMe SSD’s ability to manage the working set with consistently low latency, regardless of dataset size; larger datasets do not significantly increase cache misses or I/O wait times within this range. The Kubernetes deployment reveals a more intricate narrative: read and OLTP-mixed workloads maintain comparable scale stability (Δ < 1%), the write workload exhibits an 18.6% enhancement in TPS and a 17.1% decrease in latency when transitioning from scale 500 to scale 1000. The slight sensitivity in distributed writes presumably indicates a favorable alignment between the larger dataset’s write distribution pattern and the persistent volume’s sequential I/O characteristics, rather than a fundamental architectural effect. Although this discrepancy does not alter the study’s primary conclusions, it suggests that distributed PostgreSQL deployments exhibit somewhat greater sensitivity to dataset expansion than their monolithic counterparts—an important factor when generalizing these findings to substantially larger production datasets.

The read:write throughput ratio analysis is shown in Table 6:

Table 6. PostgreSQL read:write throughput ratio by deployment. Kubernetes amplifies the read/write asymmetry by 3× because replication overhead falls exclusively on the write path.

Deployment	Write TPS	Read TPS	Read:Write Ratio	Amplification
Monolithic	74,072	345,459	4.66×	-
Kubernetes	20,805	293,758	14.12×	3.03×

In the monolithic PostgreSQL configuration, read operations are 4.66× faster than write operations, reflecting the intrinsic asymmetry between read and write paths in a transactional RDBMS. In the Kubernetes implementation, this ratio escalates to 14.1×, representing a 3.03× amplification. The mechanism is simple: replication overhead affects only the write path (which must wait for replica acknowledgments before committing), while reads are served locally from the primary without coordination costs. The amplification of asymmetry indicates that allocating a write-intensive workload in Kubernetes does not impose a consistent burden; it systematically reallocates costs to writes.

Time-trend analysis with p-values is as shown in Table 7:

Table 7. Pearson correlation (elapsed time → per-interval TPS), n = 60 intervals. Two-sided p-values; 95% CI via Fisher z-transform. Bonferroni-corrected threshold for 12 tests: α* = 0.004.

Configuration	R	t (df = 58)	p (Two-Sided)	95% CI	Bonferroni Sig?
K8s Read, scale 500	−0.402	−3.341	0.0015	[−0.595, −0.165]	Yes
K8s Read, scale 1000	−0.351	−2.853	0.0060	[−0.555, −0.106]	Yes
K8s OLTP, scale 500	−0.275	−2.174	0.0338	[−0.494, −0.022]	No
K8s Write, scale 1000	−0.269	−2.128	0.0376	[−0.490, −0.016]	No
Mono Read, scale 500	−0.282	−2.234	0.0293	[−0.500, −0.030]	No
Mono OLTP, scale 500	−0.261	−2.061	0.0438	[−0.483, −0.008]	No
Mono Read, scale 1000	−0.246	−1.936	0.0577	[−0.471, +0.008]	No
K8s Write, scale 500	+0.043	+0.325	0.746	[−0.214, +0.293]	No
Mono Write, scale 500	−0.009	−0.071	0.944	[−0.263, +0.245]	No

Applying Bonferroni correction for twelve simultaneous tests (α* = 0.004), only the two Kubernetes read workloads show correlations surviving correction: scale 500, r = −0.402, p = 0.0015, 95% CI [−0.595, −0.165]; scale 1000, r = −0.351, p = 0.0060, 95% CI [−0.555, −0.106]. The absence of any significant trend in write workloads—including all Kubernetes write runs—indicates that K8s write instability (CV 40–42%) is a random, non-systematic process consistent with sporadic replication coordination delays rather than progressive resource exhaustion.

PostgreSQL demonstrates a distinct sensitivity to distributed execution. The noted decline in throughput and rise in latency can be attributed to coordination costs arising from replication and inter-node communication. PostgreSQL also exhibits one of the most significant performance disparities between monolithic and distributed installations among the systems subsequently assessed, underscoring its robust optimization for vertically scaled environments. Resource use patterns suggest that the distributed deployment is constrained not by hardware capacity but by the complexity of orchestration and synchronization. These findings underscore PostgreSQL’s appropriateness for latency-sensitive transactional tasks, especially in a single-node setup.

4.2. MySQL

MySQL was assessed in analogous situations to enable a comparative analysis of relational database systems. The findings demonstrate the response of an alternative engine to distributed deployment.

4.2.1. Performance Results

Table 8 shows the throughput and latency recorded for MySQL:

Table 8. MySQL performance summary: monolithic vs. Kubernetes (PXC) across all sysbench workload types. Means across runs (monolith n = 2; K8s n = 4). 95% CIs from run-level replicates.

Workload	Deploy	n	Mean TPS	95% CI	CV%	Avg Lat (ms)	p95 lat (ms)	Max Lat (ms)	Threads
oltp_read_only	Monolithic	2	15,392	[14,798–15,987]	0.4%	2.33	4.21	40.7	36
oltp_read_only	Kubernetes	4	9645	[7978–11,311]	10.9%	7.53	25.70	507.3	72
oltp_point_select	Monolithic	2	410,677	[400,661–420,693]	0.3%	0.09	0.20	20.9	36
oltp_point_select	Kubernetes	4	211,117	[202,713–219,521]	2.5%	0.34	0.78	83.7	72
oltp_write_only	Monolithic	2	4718	[4383–5052]	0.8%	5.08	12.52	461.9	24
oltp_write_only	Kubernetes	4	6476	[4599–8354]	18.2%	10.13	20.29	12,264	64
oltp_update_index	Monolithic	2	15,727	[15,082–16,372]	0.5%	3.05	6.67	348.7	48
oltp_update_index	Kubernetes	4	14,775	[9567–19,983]	22.2%	4.50	8.96	11,110	64
oltp_read_write	Monolithic	2	4062	[3707–4416]	1.0%	5.91	11.97	346.5	24
oltp_read_write	Kubernetes	4	3912	[3333–4492]	9.3%	18.52	53.48	9772	72

Unlike PostgreSQL, throughput remains consistently stable across deployment patterns; however, latency significantly escalates in the distributed setup.

MySQL exhibits a heterogeneous performance profile that differentiates it from the other relational systems assessed in this study. Read-intensive workloads significantly deteriorate in the Kubernetes PXC implementation. Write-only workloads, nevertheless, exhibit the opposite trend—the sole instance among all five assessed systems in which a Kubernetes deployment surpasses its monolithic equivalent in throughput. Update and mixed workloads occupy an intermediate position: throughput remains largely consistent between deployments, latency increases significantly in Kubernetes, and confidence intervals expand markedly, indicating run-to-run variability due to the Galera cluster’s warm-up behavior. The results illustrate the architectural features of the Percona XtraDB Cluster: its Galera-based multi-primary replication efficiently distributes write load, but introduces network overhead that adversely impacts read latency, as shown in Table 9:

Table 9. MySQL throughput and latency change from monolithic to Kubernetes.

Workload	Mono TPS	K8s TPS	TPS Δ%	Mono Avg Lat	K8s Avg Lat	Lat Inflation	Pattern
oltp_read_only	15,392	9645	−37.3%	2.33 ms	7.53 ms	3.22×	K8s WORSE
oltp_point_select	410,677	211,117	−48.6%	0.09 ms	0.34 ms	3.81×	K8s WORSE
oltp_write_only	4718	6476	+37.3%	5.08 ms	10.13 ms	2.00×	K8s FASTER
oltp_update_index	15,727	14,775	−6.1%	3.05 ms	4.50 ms	1.47×	Near-equal TPS
oltp_read_write	4062	3912	−3.7%	5.91 ms	18.52 ms	3.13×	TPS ~equal, lat high

Read-oriented workloads demonstrate good stability in both monolithic and Kubernetes deployments, indicating that read performance is consistently predictable regardless of deployment mode. Write and update workloads exhibit moderate stability in the monolith but deteriorate to low stability in Kubernetes, characterized by significant fluctuations, including near-total write stalls that recover in the subsequent measurement window. The mixed read–write workload shows low stability across both systems, driven by intermittent InnoDB lock contention in the monolith and cumulative replication latency in Kubernetes.

Table 10 reports interval-level throughput stability across workload types and deployments, revealing considerable variation across configurations:

Table 10. MySQL throughput stability (CV%) from interval-level measurements. n = number of 10-s measurement intervals. Stability classification: HIGH = CV < 15%, MEDIUM = 15–30%, LOW ≥ 30%.

Workload	Deployment	Tables	n (Intervals)	Mean TPS	StdDev (TPS)	CV%	Min TPS	Max TPS	Stability
oltp_read_only	Monolithic	100	30	15,439	815	5.3%	15,237	19,748	HIGH
oltp_read_only	Monolithic	200	30	15,346	517	3.4%	15,204	18,080	HIGH
oltp_read_only	Kubernetes	100–200	60	9645	1045	10.8–11.9%	8362	13,573	HIGH
oltp_point_select	Monolithic	100–200	30	410,700	13,170	3.2%	406,817	480,557	HIGH
oltp_point_select	Kubernetes	100–200	60	211,120	12,890	5.5–6.7%	200,352	276,951	HIGH
oltp_write_only	Monolithic	100	30	4692	974	20.8%	1550	5399	MEDIUM
oltp_write_only	Monolithic	200	30	4745	942	19.9%	1077	5444	MEDIUM
oltp_write_only	Kubernetes	100	60	6494	3159	48.7%	149	10,887	LOW
oltp_write_only	Kubernetes	200	60	6462	3328	51.5%	10	11,421	LOW
oltp_update_index	Monolithic	100–200	30	15,728	4555	28.9%	3987	19,438	MEDIUM
oltp_update_index	Kubernetes	100–200	60	14,775	5990	35–46%	1517	25,376	LOW
oltp_read_write	Monolithic	100–200	60	14,870	10,924	73.4%	870	28,119	LOW
oltp_read_write	Kubernetes	100–200	120	6819	3012	43.5–44.8%	1054	11,367	LOW

Table 10 reports interval-level throughput stability across workload types and deployments. Throughput stability varies significantly across workload types and deployments. Read-oriented workloads demonstrate good stability in both monolithic and Kubernetes deployments, signifying that read performance is reliably predictable irrespective of deployment mode. In the monolith, write and update workloads exhibit moderate stability; however, in Kubernetes, they deteriorate to low stability, characterized by significant fluctuations, including near-total write stalls that recover in the subsequent measurement window. The mixed read–write workload shows low stability across both systems, driven by intermittent InnoDB lock contention in the monolith and cumulative replication latency in Kubernetes.

Table 11 presents Pearson correlation coefficients between elapsed time and per-interval throughput for each MySQL run, testing for systematic trends within individual benchmark executions:

Table 11. Pearson r (elapsed time → TPS) for MySQL runs. n = 30 or 60 intervals. Two-sided p-values; 95% CI via Fisher z-transform. Positive r = throughput rises over time; negative r = throughput falls.

Workload	Deployment	n	r	p (Two-Sided)	95% CI	Interpretation
oltp_read_write	Monolithic	60	+0.852–0.855	p < 0.001	[+0.764, +0.911]	InnoDB crash-recovery cycle dominates fit
oltp_read_write	Kubernetes	60	+0.820–0.839	p < 0.001	[+0.714, +0.901]	Same pattern; consistent across all 4 runs
oltp_write_only	Monolithic	30	−0.369	0.0447	[−0.644, −0.010]	Mild decline—gradual write contention
oltp_update_index	Monolithic	30	−0.421	0.0204	[−0.679, −0.072]	Mild decline—index contention
oltp_point_select	Kubernetes (200t)	30	−0.409	0.0247	[−0.671, −0.057]	Mild decline—HAProxy/buffer saturation
oltp_read_only	Monolithic	30	−0.34 to −0.36	p > 0.05	CIs include 0	No significant trend
oltp_write_only	Kubernetes	30	−0.06 to −0.13	p > 0.50	CIs include 0	No trend—variability random, not progressive

Table 11 demonstrates one of the most diagnostically significant patterns in the MySQL dataset. All oltp_read_write executions—both in monolithic and Kubernetes deployments—exhibit robust, statistically significant upward trends over time, initially indicating increased throughput. This does not represent a true warm-up advantage; instead, it illustrates a typical crash-and-recovery cycle in which throughput initially approaches its zenith, declines mid-execution due to InnoDB lock contention, and then gradually recovers. The recovery phase predominates the linear fit for the entire run duration. Write and update workloads exhibit slight yet statistically significant declining trends in the monolith, aligning with gradual lock accumulation, whereas all Kubernetes write executions demonstrate no significant temporal trend, thereby affirming that Kubernetes write instability is random and non-progressive rather than indicative of systematic degradation.

Table 12 compares MySQL performance between the 100-table and 200-table dataset configurations, assessing whether results are sensitive to dataset size in either deployment mode:

Table 12. MySQL performance change between 100-table and 200-table dataset configurations. All |Δ| < 5% confirms complete scale invariance within the tested range.

Workload	Deployment	100-Table TPS	200-Table TPS	Δ%	Scale-Stable?
oltp_read_only	Monolithic	15,439	15,346	−0.6%	Yes
oltp_read_only	Kubernetes	9642	9648	+0.1%	Yes
oltp_point_select	Monolithic	411,466	409,889	−0.4%	Yes
oltp_point_select	Kubernetes	210,988	211,247	+0.1%	Yes
oltp_write_only	Monolithic	4692	4745	+1.1%	Yes
oltp_write_only	Kubernetes	6493	6459	−0.5%	Yes
oltp_update_index	Monolithic	15,778	15,676	−0.6%	Yes
oltp_update_index	Kubernetes	14,776	14,773	−0.0%	Yes
oltp_read_write	Monolithic	4034	4090	+1.4%	Yes
oltp_read_write	Kubernetes	3996	3829	−4.2%	Yes

Table 12 confirms that MySQL performance exhibits perfect scale invariance across the two table-count configurations evaluated, in both monolithic and Kubernetes installations. The performance disparities between the 100-table and 200-table configurations are minimal across all workload types, suggesting that InnoDB’s buffer pool effectively manages both dataset sizes inside its working set without significant cache pressure. This outcome reinforces the legitimacy of comparisons among deployments, affirming that the noted performance disparities are attributable to architectural elements rather than byproducts of dataset size.

Table 13 reports throughput and latency for the two independent Kubernetes baseline runs at each configuration, quantifying how much performance varies between successive runs of the same workload:

Table 13. MySQL Kubernetes run-to-run variability: Baseline Run 1 vs. Run 2 TPS and average latency, by workload and table scale.

Workload	Tables	R1 TPS	R2 TPS	TPS Diff%	R1 Avg Lat (ms)	R2 Avg Lat (ms)	Reproducible?
oltp_read_only	100	8661	10,623	+22.7%	8.31 ms	6.78 ms	Poor
oltp_point_select	100	207,582	214,394	+3.3%	0.35 ms	0.34 ms	Good
oltp_write_only	100	5682	7304	+28.5%	11.26 ms	8.76 ms	Poor
oltp_update_index	100	12,108	17,445	+44.1%	5.28 ms	3.67 ms	Poor
oltp_write_only	200	5263	7655	+45.4%	12.16 ms	8.36 ms	Poor
oltp_read_write	100	3946	4046	+2.5%	18.24 ms	17.79 ms	Good

Table 13 demonstrates significant run-to-run variability in the Kubernetes deployment, especially for write-intensive workloads. The second baseline run consistently achieves significantly higher throughput and lower latency than the first under identical configurations, reflecting the warm-up behavior of the Galera cluster: the initial run incurs additional inter-node synchronization overhead as the cluster establishes its write-set certification state, which diminishes in subsequent runs. Read workloads and mixed workloads have significantly reduced inter-run variations, indicating that the warm-up impact is particular to the write certification process. This discovery has a practical implication: benchmarking Galera-based MySQL clusters requires either a dedicated warm-up phase or numerous iterations to obtain consistent results.

4.2.2. MySQL Analysis

MySQL has a more variable reaction to distribution. Although latency increases considerably, throughput is maintained by increased concurrency. This pattern contrasts with PostgreSQL, where both throughput and latency deteriorate more significantly.

MySQL demonstrates a heterogeneous deployment profile, in contrast to the other assessed relational systems. Three distinct patterns emerge: read-intensive workloads deteriorate in Kubernetes (oltp_read_only −37.3%, oltp_point_select −48.6%); write-intensive workloads exhibit improvement (+37.3% for oltp_write_only), enabled by PXC’s multi-primary write distribution; and update and mixed workloads demonstrate comparable TPS but significantly increased latency in K8s (oltp_read_write: 5.91 ms mono vs. 18.52 ms K8s, 3.13×). This aligns with PXC’s Galera-based synchronous replication design, optimized for write distribution at the expense of per-transaction latency.

The findings indicate that MySQL may use horizontal scaling more effectively for throughput; however, it still incurs unavoidable latency penalties due to coordination overhead. This underscores a significant distinction: not all relational systems respond uniformly to distributed deployment, even when subjected to analogous workloads.

Thus, MySQL may be more appropriate than PostgreSQL in distributed settings where throughput is emphasized over latency.

4.3. MongoDB

MongoDB was assessed using various workload profiles to encompass a spectrum of application scenarios, including read-intensive, write-intensive, and mixed workloads.

4.3.1. Monolithic Performance

Table 14 presents MongoDB performance in the monolithic deployment across the four YCSB workload profiles, including read and update latency at the average and 99th-percentile levels.

Table 14. MongoDB performance in monolithic deployment. YCSB workload profiles, 10M record dataset, 64 threads. All latency values in µs. p99 values reveal tail behaviour under single-node write contention.

Workload	Description	TPS (ops/sec)	Avg Read Lat (µs)	p95 Read (µs)	p99 Read (µs)	Avg Update Lat (µs)	p99 Update (µs)
C (read-only)	100% read	4202	5039	59,423	60,639	—	—
B (read-heavy)	95% read/5% update	4739	3123	30,935	38,655	2702	39,071
A (balanced)	50% read/50% update	4630	3691	35,967	55,391	4213	—
F (read–modify–write)	50% read/50% RMW	4545	3234	43,511	48,255	1749	45,535

MongoDB in the monolithic deployment provides generally consistent throughput across the four YCSB workload profiles evaluated. Throughput is consistently stable across various workloads, including read-only, read-heavy, balanced, and read–modify–write, suggesting that the monolithic arrangement accommodates all access patterns within a comparable performance range. The average read delay is minimal in read-heavy workloads and increases marginally as the proportion of updates rises, indicating the additional burden from write operations in WiredTiger’s MVCC paradigm. The elevated p99 latency values across all workloads indicate sporadic, substantial tail events during prolonged single-node write contention that are not discernible from mean values alone.

4.3.2. Distributed Performance

The effects of Kubernetes deployment are illustrated in Table 15.

Table 15. MongoDB performance in Kubernetes distributed deployment (10M records, 64 threads). All latency values in µs. Ranges reflect variation across 5M and 10M dataset sizes and multiple runs.

Workload	TPS (ops/sec)	Avg Read Lat (µs)	Avg Update Lat (µs)	Update/Read Ratio	TPS Change vs. Monolithic
C (read-only)	2646–2924	10,511–12,372	—	—	−33% to −38%
B (read-heavy)	2771–3058	10,147–10,760	11,487–12,470	1.13×	−35% to −42%
A (balanced)	2451–2786	9264–9720	13,819–18,323	1.49×	−40% to −47%
F (read–modify–write)	2257–2771	8238	5667	—	−39% to −50%

Deploying MongoDB as a Kubernetes replica set consistently reduces throughput and significantly increases latency compared to a monolithic deployment across all demand profiles. The ranges documented across dataset sizes and multiple executions demonstrate substantial variability in the distributed configuration, especially for update operations, in contrast to the stricter consistency noted in the monolithic deployment.

The next evaluation is related to MongoDB throughput scalability, as shown in Table 16:

Table 16. MongoDB throughput scalability (64 → 200 threads). Scalability ratio < 1.0 = regression. The monolithic Workload A regression is the only throughput reversal observed across all systems in this study.

Workload	Description	Deployment	64-Thread TPS	200-Thread TPS	Scalability Ratio	Interpretation
C	100% read	Monolithic	4516	81,470	18.0×	Near-linear scaling
C	100% read	Kubernetes	2853	87,825	30.8×	Super-linear—secondary read offloading
B	95/5 read-update	Monolithic	4833	74,850	15.5×	Strong scaling
A	50/50 read-update	Monolithic	91,333	54,247	0.59×	Regression—write contention ceiling
A	50/50 read-update	Kubernetes	5476	18,425	3.37×	Moderate—no regression
F	50% read/50% RMW	Monolithic	4289	44,557	10.4×	Good scaling

The monolithic MongoDB deployment exhibits a decline in throughput under Workload A at 200 threads, from approximately 91,333 to 54,247 ops/sec (−41%, scalability ratio of 0.59×). This results from MVCC lock contention during high-concurrency mixed read–write access, where conflicting update operations impede one another in WiredTiger. The Kubernetes deployment does not demonstrate this problem, as the replica set allocates update operations and the principal write path experiences less contention. Independently, Workload C (read-only) at 200 threads exhibits super-linear scaling in Kubernetes (30.8×), attributable to secondary-read offloading, attaining 87,825 ops/sec—the sole setting in this analysis where a Kubernetes deployment surpasses its monolithic counterpart.

Table 17 examines the ratio of update latency to read latency within each MongoDB deployment, using this ratio as a sensitive indicator of the additional write-path overhead introduced by replication:

Table 17. MongoDB update-to-read latency ratio across deployment modes. A ratio > 1.0 means updates are slower than reads; the increase from monolithic to Kubernetes reflects the additional write-path penalty imposed by replication.

Deployment	Workload	Avg Read Lat (µs)	Avg Update Lat (µs)	Update/Read Ratio	Interpretation
Monolithic	A (50/50)	3691	4213	1.14×	Modest write overhead
Monolithic	B (95/5)	3123	2702	0.87×	Slower reads
Monolithic	F (RMW)	3234	1749	0.54×	Fast atomic RMW
Kubernetes	A (50/50)	9264	13,819	1.49×	+31% write penalty relative to monolithic
Kubernetes	B (95/5)	10,147	11,487	1.13×	Modest increase

In the monolithic deployment, Workload A exhibits an update latency of 1.14 times the read latency, indicating a slight overhead commensurate with local Write-Ahead Logging and journal commitments. In Kubernetes, the ratio increases to 1.49×, representing a 31-percentage-point gain. This excessive update latency inflation verifies that replication within the MongoDB replica set incurs overhead specifically on the write path: each acknowledged write must be propagated to at least one secondary before the client receives confirmation, resulting in a network round-trip that is not present in reads. This pattern is uniform across workload categories and serves as structural evidence of distributed write amplification.

4.3.3. MongoDB Analysis

MongoDB exhibits a performance pattern directionally similar to PostgreSQL—distributed deployment consistently degrades both throughput and latency—though the two systems are measured with different tools and workloads and are not directly numerically comparable. Distributed deployment leads to diminished performance and heightened latency, especially for read operations.

In contrast to relational systems, MongoDB’s performance is not limited by hardware use, as CPU and storage usage are kept to a minimum. This indicates that performance deterioration is mostly influenced by network latency and coordination procedures rather than resource constraints.

The findings suggest that although MongoDB is engineered for distributed contexts, it does not inherently benefit from distribution under moderate workloads and may incur performance drawbacks akin to those of relational systems.

4.4. Redis

Redis was evaluated as a high-performance in-memory system, providing a reference point for the upper limits of monolithic database performance.

4.4.1. Performance Results

Table 18 presents Redis throughput and full latency percentile data for SET and GET operations under the baseline benchmark configuration:

Table 18. Redis performance at baseline configuration (50 clients, 256-byte payload, 100k operations, no pipelining).

Operation	Throughput (ops/sec)	Avg Lat (ms)	Min (ms)	p50 (ms)	p90 (ms)	p99 (ms)	Max (ms)
SET	257,732	0.101	0.024	0.103	0.103	0.231	1.127
GET	262,467	0.098	0.032	0.095	0.103	0.191	0.327

Table 18 confirms that Redis provides outstanding throughput with sub-millisecond latency for both SET and GET operations under standard settings. Performance is highly consistent across the two operation types, and the tight latency distribution—with p99 remaining well below one millisecond—reflects the predictability of in-memory key-value access with no coordination overhead.

Table 19 presents the comprehensive ranking of Redis operation throughput across eleven operation categories in pipelined, high-throughput scenarios, including average and tail latency metrics:

Table 19. Redis full operation throughput ranking (pipelined: 200 clients, 1024-byte payload, pipeline depth 64, 10M operations). Ranked by throughput.

Rank	Operation	Type	Throughput (ops/sec)	Avg Lat (ms)	p99 (ms)	p99/Avg Ratio	Complexity
1	SPOP	Set pop	4,182,350	2.9	10.2	3.6×	O(1)
2	SADD	Set add	2,468,526	4.9	9.2	1.9×	O(1)
3	INCR	Increment	2,218,771	5.5	9.3	1.7×	O(1)
4	RPOP	List pop (right)	1,487,210	7.9	11.5	1.5×	O(1)
5	LPOP	List pop (left)	1,478,634	7.9	12.7	1.6×	O(1)
6	RPUSH	List push (right)	1,121,831	4.0	5.6	1.4×	O(1)
7	LPUSH	List push (left)	1,105,828	4.1	4.9	1.2×	O(1)
8	HSET	Hash set	978,474	4.6	6.1	1.3×	O(1)
9	GET	String get	956,938	12.6	17.5	1.4×	O(1)
10	SET	String set	940,203	4.9	6.4	1.3×	O(1)
11	ZADD	Sorted set add	491,014	25.8	32.0	1.2×	O(log N)

Table 19 shows that throughput varies significantly across Redis operation types, even within a single in-memory system. All O(1) operations are concentrated inside a limited range, indicating that for basic data structures, throughput is constrained by network serialization rather than computational expense. The sorted-set operation is the distinct outlier, attaining significantly poorer performance than all other operation types due to the logarithmic complexity of its insertion mechanism. The p99-to-average latency ratio varies across activities, with set-based operations exhibiting elevated tail ratios, possibly indicating sporadic contention when multiple clients access the same underlying data structure.

4.4.2. Redis Analysis

Redis significantly outperforms all other systems in both throughput and latency. This is primarily due to its in-memory architecture and lack of distributed coordination.

In contrast to Cassandra, which also achieves high throughput, Redis demonstrates that reducing network overhead can significantly lower latency. This performance entails compromises in scalability and persistence.

Redis thus epitomizes the maximum performance attainable in monolithic systems, serving as a benchmark for evaluating other designs.

4.5. Cassandra

Cassandra was evaluated as a distributed system designed for scalability and high availability.

4.5.1. Performance Results

Table 20 provides a comprehensive statistical assessment of Cassandra’s performance across various workload types and consistency levels, encompassing percentile latency tiers and run-to-run variability.

Table 20. Cassandra’s performance in a distributed Kubernetes deployment. Means across multiple runs at 5M and 10M partition dataset sizes. All latency values in ms.

Workload	Consistency	n	Mean ops/sec	CV%	Avg Lat (ms)	Median (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)	p99.9/Mean
Write	ONE	4	157,477	7.1%	1.23	0.60	4.20	9.40	42.4	34.2×
Write	QUORUM	5	86,340	84.7%	3.16	1.48	9.94	22.58	149.1	40.8×
Read	ONE	7	214,743	2.7%	0.90	0.70	1.90	4.34	12.3	13.6×
Mixed (R + W)	QUORUM	4	67,540	12.1%	2.95	1.88	7.47	21.85	56.9	18.9×

Table 20 indicates that Cassandra’s performance characteristics are significantly influenced by the selected consistency level. Reading workloads at ONE consistency yields the highest throughput and lowest latency across all distributed configurations in this investigation, demonstrating exceptional run-to-run stability. Writing workloads at ONE achieve robust throughput with minimal variability; however, transitioning to QUORUM consistency significantly reduces throughput, increases latency, and markedly amplifies run-to-run variability, making QUORUM write performance the most unpredictable configuration across all assessed systems and deployments. The mixed workload at QUORUM occupies a middle ground, indicating the aggregate expense of implementing QUORUM limitations on both read and write operations.

Table 21 presents Pearson correlation coefficients and inferential statistics about the association between Cassandra consistency levels and key performance indicators across all write benchmark executions.

Table 21. Pearson correlation: consistency level (ONE = 1, QUORUM = 2) vs. performance metrics across n = 8 Cassandra write benchmark runs. Two-sided p-values; 95% CI via Fisher z-transform.

Metric	r	t (df = 6)	Two-Sided p	95% CI for r	Interpretation
Consistency → Throughput	−0.983	−13.15	p < 0.001 (1.2 × 10−5)	[−0.997, −0.906]	Near-perfect negative linear
Consistency → Avg latency	+0.917	+5.643	p = 0.0013	[+0.601, +0.985]	Very strong positive linear
Consistency → p99 latency	+0.649	+2.088	p = 0.0818	[−0.103, +0.929]	Not significant at α = 0.05

Table 21 provides empirical evidence of the correlation between consistency level and performance. The correlation between consistency level and throughput is nearly perfectly linear and highly significant, as is the correlation with average latency, confirming that the performance cost of enhancing consistency is not a threshold effect but a proportional, predictable penalty across the evaluated configurations. The correlation with p99 latency, although positive, does not reach statistical significance at this sample size, suggesting that factors beyond the consistency level alone influence tail latency.

Table 22 quantifies the performance penalty associated with transitioning from ONE to QUORUM consistency across all evaluated dimensions, including mean throughput, extreme tail latency, and run-to-run variability:

Table 22. Quantified cost of moving from ONE to QUORUM consistency for Cassandra write workloads. All figures are means across runs at 5M and 10M partition dataset sizes.

Metric	Consistency: ONE	Consistency: QUORUM	QUORUM Penalty
Mean throughput (ops/sec)	157,477	86,340	−45.2% (−71,137 ops/sec)
Average latency (ms)	1.23	3.16	+2.58× inflation
Median latency (ms)	0.60	1.48	+2.47×
p95 latency (ms)	4.20	9.94	+2.37×
p99 latency (ms)	9.40	22.58	+2.40×
p99.9 latency (ms)	42.4	149.1	+3.52×
p99.9/mean tail spread	34.2×	40.8×	+19.3% wider distribution
Run-to-run CV%	7.1%	84.7%	+77.6 pp (+1094% more variable)

Table 22 quantifies the comprehensive cost of transitioning from ONE to QUORUM consistency across all evaluated dimensions. The drop in throughput and increase in latency are considerable; nevertheless, the most operationally critical observation is the behavior at the extremes: the p99.9 latency escalates significantly more than the mean, and run-to-run variability rises markedly. QUORUM consistency entails not a uniform latency threshold but rather a high-variance, tail-heavy penalty, in which the most adversely impacted requests endure delays that significantly exceed those implied by mean or even p99 metrics.

4.5.2. Cassandra Analysis

Cassandra demonstrates the strengths of distributed database architecture. It achieves high throughput through parallel execution across nodes, particularly for read operations.

Compared to Redis, Cassandra incurs slightly higher latency due to network communication, but offers significantly greater scalability and fault tolerance. Unlike MongoDB and PostgreSQL, Cassandra benefits from distribution because its architecture is explicitly designed for partitioned, horizontally scalable workloads.

These results confirm that distributed systems can outperform monolithic systems in throughput when designed for scalability, particularly under relaxed consistency constraints.

4.6. Comparative Analysis

The subsequent subsections provide a comprehensive comparison of the assessed database systems to emphasize significant performance trends across designs. This comparison highlights relative variations in throughput and latency, rather than analyzing individual systems in isolation, thereby clarifying how architectural decisions affect overall system performance. The study reveals overarching trends by aggregating results that are not readily discernible from individual system evaluations alone.

Alongside throughput and delay, resource utilization was assessed throughout all studies. CPU and memory utilization consistently stayed below saturation limits in both monolithic and distributed configurations for all assessed systems. No setup demonstrated persistent CPU or memory depletion that would suggest hardware-level constraints. Performance reduction in remote deployments was consistently linked to coordination overhead, network latency, and replication techniques, rather than resource constraints. These observations affirm that the performance disparities are primarily due to architectural and orchestration factors, rather than to inadequate computational or memory resources.

4.6.1. Throughput Comparison

Table 23 summarizes peak throughput across all systems:

Table 23. Peak throughput across all evaluated systems and deployments.

System	Architecture	Workload	Max TPS/ops/sec	Avg Latency (ms)
Redis	Monolithic	SPOP (pipelined)	4,182,350	2.9
Redis	Monolithic	SET/GET (baseline)	257,732–262,467	0.098–0.101
MySQL	Monolithic	oltp_point_select	410,677	0.09
Cassandra	Kubernetes	Read ONE	214,743	0.90
MySQL	Kubernetes	oltp_point_select	211,117	0.34
Cassandra	Kubernetes	Write ONE	157,477	1.23
PostgreSQL	Monolithic	Read	345,459	0.208
PostgreSQL	Kubernetes	Read	293,758	0.195
PostgreSQL	Monolithic	Write/OLTP	74,072–78,186	0.918–0.969
MongoDB	Monolithic	All workloads (64 threads)	4202–4739	3.1–5.0
MySQL	Monolithic	oltp_read_only/write	4718–15,392	2.33–5.08
MongoDB	Kubernetes	All workloads (64 threads)	2257–3058	8.2–12.4
MySQL	Kubernetes	oltp_read_write	3912	18.52

Both monolithic and distributed architectures can achieve high peak throughput; however, the findings indicate that this capability is predominantly influenced by architectural design rather than solely by deployment strategy. Redis and MySQL achieve the highest throughput among monolithic systems through distinct mechanisms: in-memory access and optimized single-row keyed reads, respectively. In contrast, Cassandra attains similar distributed throughput due to its design for partitioned horizontal execution. The remaining systems aggregate at significantly reduced throughput, with distributed implementations of general-purpose relational and document databases consistently underachieving relative to their monolithic equivalents, thereby affirming that distribution alone does not confer a throughput benefit unless the system’s architecture is specifically engineered to leverage it.

The study indicates that in-memory monolithic systems achieve the highest performance, closely followed by purpose-built distributed architectures operating under relaxed consistency. In distributed Kubernetes installations, general-purpose relational and document databases consistently exhibit lower throughput, regardless of the number of client threads used.

4.6.2. Latency Overview

Table 24 summarises the minimum observed average latency for each system and workload category, providing a consolidated view of the latency floor achievable under each architectural configuration.

Table 24. Minimum observed average latency across all evaluated systems and workload categories.

System	Architecture	Workload	Avg Latency (ms)	p95 (ms)	Note
MySQL	Monolithic	oltp_point_select	0.09	0.20	Single-row keyed reads
Redis	Monolithic	GET (baseline)	0.098	0.103	In-memory, no coordination
PostgreSQL	Monolithic	Read	0.208	—	Buffered sequential reads
PostgreSQL	Kubernetes	Read	0.195	—	Minimal overhead—read-only
Cassandra	Kubernetes	Read ONE	0.90	1.90	Distributed; median 0.7 ms.
Cassandra	Kubernetes	Write ONE	1.23	4.20	Replication at relaxed consistency
PostgreSQL	Monolithic	Write/OLTP	0.918–0.969	—	WAL + storage bound
MySQL	Monolithic	oltp_read_write	5.91	11.97	Mixed contention
PostgreSQL	Kubernetes	Write	3.059	—	Replication overhead
MySQL	Kubernetes	oltp_read_write	18.52	53.48	Highest avg latency in study

Table 24 confirms that the lowest latencies in the study are achieved by in-memory and read-optimized monolithic systems, in which data locality eliminates coordination overhead. Distributed systems achieve optimal latency only when the foundational architecture is intentionally designed for distributed execution, as exemplified by Cassandra with ONE consistency. Latency significantly increases across all general-purpose systems in Kubernetes installations, with mixed read–write workloads exhibiting the highest average latency recorded in the study.

Latency results clearly favor monolithic systems, particularly those optimized for in-memory or single-node execution.

4.6.3. Synthesis of Findings

Across all systems, a consistent pattern emerges. Monolithic databases offer lower latency and higher efficiency due to the absence of coordination overhead, whereas distributed systems introduce additional latency but enable scalability and resilience.

Importantly, the results demonstrate that architecture has a greater impact on performance than the specific database engine. Systems such as Redis and Cassandra achieve high performance not because of their data models, but because of their architectural design.

System resource usage was observed during all benchmark executions. In monolithic PostgreSQL and MySQL deployments, CPU consumption peaked at 85–95% of available cores during intensive write and OLTP workloads, while memory usage remained consistent at 8–12 GB, well within the 64 GB capacity, indicating compute saturation rather than memory limitation. In Kubernetes distributed deployments, CPU utilization per node was significantly lower (20–45% during write workloads), suggesting that performance degradation is primarily due to coordination overhead—including network round-trip time for replication acknowledgments, distributed lock management, and inter-pod communication—rather than resource exhaustion. MongoDB’s monolithic execution demonstrated persistently low CPU utilization (<30%) even during peak traffic, aligning with its event-loop I/O architecture. Redis exhibited nearly total use of a single CPU core during the first benchmarks (single-threaded server), indicating that design rather than hardware limitations determine its throughput limit. These observations confirm that distributed performance penalties are driven by coordination overhead rather than resource exhaustion across all systems.

4.6.4. Final Interpretation

Taken together, the results reveal a fundamental trade-off that directly answers the research questions of this study. Monolithic systems are best suited for latency-sensitive transactional workloads, where minimizing coordination overhead is critical. In contrast, distributed systems are better aligned with large-scale, read-intensive, and fault-tolerant applications, where scalability and availability are prioritized.

Rather than indicating a universally superior architecture, the findings suggest that optimal system design depends on workload characteristics and operational requirements. This reinforces the practical importance of hybrid architectures, which combine the strengths of both monolithic and distributed systems in modern cloud-native environments.

5. Additional Results

To ensure clarity and focus, Section 4 offers a refined compilation of the most significant experimental findings; the entire dataset is available at: https://github.com/vEddYcro/DBAppendix (accessed on 24 April 2026).

The repository contains both processed results (figures and aggregated metrics) and unprocessed, text-based benchmark outputs utilized in the investigation. These resources facilitate independent validation of the reported findings and offer further insights into performance behavior under diverse workload conditions and system configurations.

The extended results maintain the basic trends outlined in Section 4 but provide a more detailed perspective on system behavior, particularly regarding concurrent scaling, workload variability, and resource usage patterns. Consequently, they bolster the coherence and robustness of the conclusions articulated in this study.

6. Discussion

Before analyzing specific findings in depth, it is beneficial to contextualize them within the existing research. Multiple findings corroborate previously identified trends in isolated environments: the dominance of monolithic databases for low-latency transactional tasks has been recognized in relational analyses [11,23], and Cassandra’s efficacy in distributed reads has been recorded in IoT and cloud scenarios [19]. This study offers three additions that expand beyond current research. First, it illustrates these tendencies across five database systems—PostgreSQL, MySQL, MongoDB, Redis, and Cassandra—within a single controlled Kubernetes architecture, a comparison that has not been undertaken before. Second, it measures the precise impact of Kubernetes orchestration overhead on performance degradation, distinguishing it from the inherent costs of data dissemination (Section 6.3). The multi-scale, multi-concurrency findings demonstrate behaviors that cannot be anticipated from prior single-configuration research. MongoDB’s decline in write-contention throughput under high monolithic concurrency, MySQL PXC’s superior write throughput compared to its monolithic configuration, and the nearly perfect linear correlation between Cassandra’s consistency level and throughput (r = −0.983, p < 0.001). These findings collectively enhance empirical comprehension of database–infrastructure interaction in cloud-native systems.

The results indicate that database performance in Kubernetes systems is largely determined by the interplay among architectural design, workload characteristics, and orchestration-induced overhead.

6.1. Performance Attributes of Monolithic Architectures

Monolithic database deployments offer a distinct, uniform benefit for latency-sensitive transactional tasks. This phenomenon is particularly pronounced in PostgreSQL and MySQL, where single-node systems exhibit lower latency and greater efficiency than their distributed counterparts.

This benefit stems directly from architectural locality. In monolithic systems, query execution, transaction coordination, and store access occur within a single execution environment, thereby obviating the need for inter-node communication and synchronization. Consequently, transaction processing circumvents the delay penalties associated with distributed coordination.

Redis marks the upper limit of this behavior. The in-memory architecture eliminates disk I/O delay, facilitating exceptionally high throughput with sub-millisecond response times. This underscores a key principle: performance in monolithic systems is predominantly influenced by data locality and hardware efficiency, rather than coordination overhead.

This efficiency is fundamentally limited. Monolithic systems rely on vertical scaling and are ultimately constrained by the resources of a singular node. Although they perform exceptionally well in predictable, low-latency settings, they lack the scalability and fault tolerance necessary for extensive distributed systems.

6.2. Distributed Architectures: Trade-Offs in Scalability and Coordination

Distributed database systems offer distinct benefits in scalability, fault tolerance, and task allocation. Systems like Cassandra achieve high throughput by distributing data across nodes and executing requests concurrently.

This behavior exemplifies a fundamental characteristic of distributed systems: horizontal scalability is attained by partitioning tasks into independently executable parts. When workloads are efficiently partitioned—especially in read-intensive contexts—distributed systems achieve high throughput and preserve stable performance under escalating demand.

Nonetheless, this scalability incurs inevitable expenses. The processes of replication, consistency enforcement, and inter-node communication introduce coordination overhead that directly increases latency and system complexity. These impacts were uniformly found across PostgreSQL, MySQL, and MongoDB when implemented in distributed settings.

These findings align with essential characteristics of distributed systems: scalability and fault tolerance are achieved at the expense of increased coordination and communication costs. The noted performance disparities are thus not products of implementation, but rather direct outcomes of architectural design.

The results indicate that distributed deployment does not consistently enhance performance. Cassandra derives advantages from distribution because its architecture is specifically engineered for partitioned functionality. Conversely, PostgreSQL and MongoDB exhibit significant performance declines in distributed settings because their designs are ill-suited to coordination-intensive contexts.

6.3. The Function of Kubernetes as a Dynamic Performance Layer

This study concludes that Kubernetes functions as an active performance layer rather than a neutral deployment substrate. By abstracting computing, storage, and networking resources, it significantly transforms database performance in ways that cannot be solely ascribed to the database engine.

It is essential to differentiate between two sources of performance overhead in distributed Kubernetes deployments: (a) distributed architecture overhead, which stems from replication protocols, consistency enforcement, and inter-node coordination—present in any multi-node deployment irrespective of orchestration; and (b) Kubernetes orchestration overhead, which arises from container networking (via CNI plugins), persistent volume access through storage interfaces, and resource contention induced by the scheduler. The current architecture facilitates partial separation. The read performance of PostgreSQL in Kubernetes (293,758 TPS, 0.195 ms) is comparable to that of its monolithic equivalent (345,459 TPS, 0.208 ms), reflecting a 15% decrease, mostly due to container networking and storage virtualization, since reads do not require replication. Performance diminishes by an additional 66–72%, indicating the cumulative expense of replication and orchestration. MySQL offers a supplementary isolation assessment: PXC write throughput in Kubernetes rises by 37.3%, indicating that when a system is architected for distributed multi-primary write operations, the Kubernetes infrastructure overhead is outweighed by the advantages of the distributed framework. This decomposition is consistent with the findings that the Kubernetes CNI setting alone incurs a quantifiable latency penalty for stateful services [20,21].

The findings indicate that database installations in Kubernetes environments consistently experience greater delays than analogous monolithic deployments. This phenomenon results from both distributed execution and infrastructure-level overhead, encompassing network virtualization and remote storage access.

In addition to performance benefits, Kubernetes offers substantial operational advantages: automated scheduling, self-healing, and horizontal scalability significantly improve system resilience and manageability in microservice-oriented and cloud-native architectures. Collectively, these attributes convert database performance from a hardware-dependent issue to one mediated by infrastructure, necessitating a simultaneous consideration of system design and orchestration behavior.

6.4. Selection of Architecture Based on Workload

The nature of its workload significantly influences a database’s performance. No singular architecture delivers optimal performance in every case.

Monolithic systems provide enhanced performance in:

• Write-dominant tasks;
• Latency-sensitive transactional systems in contexts necessitating robust consistency;

Distributed systems exhibit optimal performance for:

• Read-intensive workloads at scale;
• Applications requiring high availability and fault tolerance across geographically distributed infrastructure.

This results in an unequivocal conclusion—the selection of database design should be dictated by workload requirements rather than deployment trends or technological biases.

The findings further indicate that architectural mismatch results in quantifiable performance decline. Implementing coordination-sensitive systems in distributed contexts lacking explicit scaling constraints incurs overhead without yielding proportional advantages.

Performance disparities among all assessed systems are predominantly influenced by the degree to which each architecture corresponds with the execution environment, rather than solely by the type of database.

6.5. Design Considerations for Cloud-Native Systems

This study’s findings have immediate relevance to the design of cloud-native database systems.

First, architectural alignment exerts a more significant influence on performance than incremental adjustment. Choosing a suitable database architecture results in considerably more benefits than fine-tuning configuration options in an incompatible system.

Second, distributed deployment ought to be a conscious design choice rather than a default presumption. Although cloud-native platforms facilitate horizontal expansion, distribution incurs quantifiable costs that genuine scalability or availability needs must validate.

Third, hybrid architectures offer a pragmatic and efficient resolution. Integrating monolithic systems for transactional workloads with distributed systems for scalable data processing enables systems to capitalize on the strengths of both paradigms while mitigating their shortcomings.

6.6. Limitations

This study offers a controlled and systematic assessment of database performance in Kubernetes systems, although it has several limitations. The experiments were conducted on a three-node cluster, facilitating reproducibility and consistent comparisons, yet failing to capture the complexity and variability inherent in large-scale production installations. While the observed performance trends reflect fundamental architectural behaviors, absolute performance parameters may vary in larger, more heterogeneous systems.

The assessment largely emphasizes throughput and latency as fundamental performance measures. Although these criteria are crucial for database benchmarking, additional factors—such as failure recovery, long-term stability, elasticity under dynamic workloads, and operating overhead—were not thoroughly examined. These factors are especially pertinent in practical cloud-native systems and may affect architectural choices beyond mere performance.

Third, database configurations were chosen to represent standard deployment techniques; however, alternative configurations—such as varying replication algorithms, consistency levels, or storage backends—may yield divergent performance outcomes. Distributed systems are particularly sensitive to configuration decisions, with performance varying with tuning and workload-specific optimizations.

Ultimately, although the Kubernetes environment was carefully controlled, factors such as network topology, storage performance fluctuations, and multi-tenant resource contention were not adequately represented. These factors can introduce significant heterogeneity in real-world cloud systems and may also affect observed performance behavior.

Notwithstanding these constraints, the experimental design describes critical variables and elucidates the essential trade-offs between monolithic and distributed database designs. The results yield significant, generalizable insights into database performance in Kubernetes-based systems and highlight crucial avenues for further research.

7. Conclusions and Future Work

This study conducts a thorough empirical evaluation of monolithic and distributed database systems within Kubernetes environments, examining the impact of architectural design on throughput, latency, and scalability across five prevalent database systems—PostgreSQL, MySQL, MongoDB, Redis, and Cassandra—utilizing standardized benchmarking frameworks across various workload types, dataset sizes, and levels of concurrency.

The results indicate that monolithic and distributed systems have inherently different performance traits. PostgreSQL achieves 74,072 TPS with an average latency of 0.969 ms in a single-node setup. In contrast, it attains 20,805 TPS with a latency of 3.059 ms in Kubernetes—a 72% decrease in throughput attributed to write-path coordination overhead rather than hardware limitations. MySQL PXC, in contrast, attains superior write throughput in Kubernetes compared to a monolithic deployment (+37.3%), illustrating that specialized distributed write architectures can gain advantages from deployment. Redis achieves a baseline throughput of 262,467 operations per second at 0.098 ms latency, scaling to 4.2 million ops/sec under pipelined conditions. Cassandra attains 214,743 operations per second for reads at ONE consistency, nearing Redis throughput within a distributed Kubernetes cluster; however, write throughput declines by 45.2% when consistency is elevated to QUORUM, accompanied by an 11-fold increase in run-to-run variability (CV 7.1% → 84.7%).

Three primary conclusions arise from the experimental data. First, architectural alignment influences performance more than engine selection: systems engineered for distributed execution (Cassandra) gain advantages from distribution, while those intended for monolithic operation (PostgreSQL, MongoDB) suffer considerable performance drawbacks. MySQL PXC holds a mediating position—advantageous for write operations but less so for read operations. Kubernetes is not a neutral deployment layer; it incurs around a 15% loss in throughput for read-only workloads, and this overhead combines multiplicatively with replication overhead for write workloads. The type of workload is the principal factor influencing architectural suitability: write-intensive OLTP workloads typically prefer monolithic deployments unless the distributed system is specifically engineered for write distribution; conversely, read-intensive, high-availability workloads favor distributed architectures.

Practitioners developing cloud-native data infrastructure should: (a) maintain monolithic or vertically scaled deployments for latency-sensitive OLTP applications necessitating strong consistency; (b) implement purpose-built distributed systems—Cassandra for extensive distributed reads, MySQL PXC or analogous for write-distributed workloads—where scalability and high availability are paramount; and (c) evaluate hybrid architectures that integrate monolithic systems for transactional workloads with distributed systems for read-scaling or analytical layers. These architectures leverage the advantages of both paradigms while alleviating their respective shortcomings.

Future research should expand this analysis in four areas: (1) larger cluster configurations (five or more nodes) to determine if distributed performance penalties decrease at a larger scale; (2) a wider array of consistency models and replication strategies, particularly synchronous versus asynchronous replication for PostgreSQL and varying write concern levels for MongoDB; (3) assessment of cloud-native database systems specifically engineered for Kubernetes—CockroachDB and YugabyteDB, TiDB—which may not demonstrate the same coordination penalties as systems originally designed for monolithic environments; and (4) longitudinal stability and failure-recovery experiments to evaluate how each architecture reacts to node failure, pod rescheduling, and network partitions under sustained load.

In conclusion, database performance in cloud-native settings arises from the interplay of architecture, infrastructure, and workload. Effective and scalable data system design requires a holistic, systems-oriented perspective that accounts for all three dimensions.