Performance Under Increasing Data Volumes

1. Introduction

The rapid growth of data-intensive applications has increased the importance of selecting appropriate database technologies. Traditional relational database management systems remain widely used because they provide structured schemas, transactional guarantees, mature query optimization, and powerful indexing mechanisms. At the same time, NoSQL databases have become increasingly popular because of their flexible data models, scalability characteristics, and suitability for particular high-volume workloads.

MongoDB is a document-oriented NoSQL database, whereas PostgreSQL is an open-source relational database management system. Their different storage and query models can lead to substantially different performance characteristics depending on the operation being performed.

Li and Manoharan compared SQL and NoSQL databases using fundamental read, write, delete, instantiate, and key-iteration operations and found that performance varied substantially by database and operation [1]. Makris et al. compared MongoDB and PostgreSQL for spatio-temporal workloads using real MarineTraffic data and a five-node AWS environment. PostgreSQL outperformed MongoDB in almost all tested queries, while indexing substantially affected response times [2].

Leung and Zhou evaluated PostgreSQL, MongoDB, SQL Server, and Redis using Twitter datasets ranging from one million to fifty million tweets, showing that database performance and suitability depend on workload and data volume [3]. Győrödi et al. compared MongoDB with document-based MySQL for CRUD operations and different data volumes, emphasizing performance differences associated with database design and workload [4]. Pantelic et al. performed a controlled single-node comparison of SQL and NoSQL persistence under read-heavy, write-heavy, and mixed workloads with varying concurrency. Their results found indexed SQL particularly strong for read-heavy workloads and MongoDB advantageous under write-intensive workloads [5].

The present study builds on this workload-dependent perspective by comparing bulk writes and indexed point reads across progressively increasing dataset sizes in a controlled local environment.

2. Research Objectives

1.      To measure bulk-write execution time for PostgreSQL and MongoDB.

2.      To measure indexed point-read latency for both databases.

3.      To evaluate performance across increasing dataset sizes.

4.      To examine run-to-run performance variability.

5.      To determine whether one database consistently outperforms the other across the tested workloads.

6.      To identify workload-dependent performance differences that can help guide database selection.

3. Research Questions

7.      How does the bulk-write performance of PostgreSQL compare with MongoDB as dataset size increases?

8.      How does indexed point-read latency differ between PostgreSQL and MongoDB across increasing dataset sizes?

9.      How consistent are PostgreSQL and MongoDB across repeated benchmark runs?

10.   Does one database demonstrate superior performance across both write-intensive and indexed-read workloads?

4. Research Hypotheses

11.   MongoDB will demonstrate lower bulk-write execution time than PostgreSQL for write-intensive workloads.

12.   PostgreSQL will demonstrate lower latency for indexed point-read operations.

13.   The performance difference between PostgreSQL and MongoDB will vary as dataset size increases.

14.   Repeated executions will demonstrate measurable run-to-run variability, particularly for write-intensive workloads.

5. Related Work

5.1 SQL and NoSQL Performance

Li and Manoharan designed a common key-value framework to compare SQL and NoSQL databases. Their measurements included read, write, delete, instantiate, and iteration operations. They concluded that NoSQL systems do not universally outperform SQL systems and that performance varies by operation [1].

5.2 PostgreSQL and MongoDB for Spatio-Temporal Data

Makris et al. compared MongoDB with PostgreSQL/PostGIS using real AIS vessel-tracking data in a five-node AWS cluster. PostgreSQL outperformed MongoDB in almost all of the tested spatio-temporal queries, and indexing substantially reduced response times [2].

5.3 Large Social-Media Datasets

Leung and Zhou compared four database systems using Twitter datasets from one million to fifty million tweets. Their work examined SQL and NoSQL performance at large data volumes without making distributed scalability the primary variable [3].

5.4 CRUD and Document-Oriented Data

Győrödi et al. compared MongoDB and document-based MySQL for CRUD operations and different data volumes in a big-data application context. Their results demonstrate the importance of considering the operation and application workload when selecting a database [4].

5.5 Variable Workloads and Concurrency

Pantelic et al. evaluated indexed SQL, non-indexed SQL, and MongoDB in a controlled single-node microservice environment under read-heavy, write-heavy, and mixed workloads with concurrency from 1 to 1000 requests. Their results indicated that indexed SQL was particularly effective for read-heavy workloads while MongoDB was advantageous for write-heavy workloads [5].

6. Research Gap

Existing research has already extensively compared SQL and NoSQL databases. Therefore, this study does not claim that PostgreSQL and MongoDB have not previously been compared. Instead, the study focuses on a narrower experimental configuration.

Previous studies have examined key-value operations, complex spatio-temporal queries, social-media datasets, CRUD workloads, microservice concurrency, throughput, and resource utilization. The present study combines two complementary workloads—bulk writes and indexed point reads—with progressively increasing dataset sizes in a controlled local environment and explicitly considers run-to-run variability using standard deviation and coefficient of variation.

The research gap can therefore be expressed as follows: there is value in a controlled empirical comparison that isolates bulk-write performance and indexed point-read latency while varying dataset size and examining run-to-run variability under a reproducible single-machine configuration.

7. Methodology

7.1 Experimental Design

The experiment compares PostgreSQL and MongoDB using four dataset sizes. Each database/dataset configuration was executed five times.

Dataset	Records
D1	10,000
D2	50,000
D3	100,000
D4	500,000

7.2 Dataset

Synthetic structured records were generated for the experiment. The same generated dataset was used for PostgreSQL and MongoDB at each dataset size, providing equivalent input data for both systems. The benchmark records contained fields representing an identifier and common structured attributes such as name, email, age, city, salary, department, and creation date.

7.3 Write Workload

The write experiment measured the time required to insert the generated dataset into each database. PostgreSQL stored the records in a relational table and MongoDB stored them in a document collection. Execution time was measured using Python's high-resolution performance timer. Five runs were performed for each database and dataset size, producing 40 write observations.

7.4 Indexed Read Workload

The improved read experiment performed 1,000 indexed point lookups during each measurement. The same lookup identifiers were used for both systems. Five runs were performed for each database and dataset size, producing 40 read observations.

7.5 Performance Metrics

Mean execution time, median, standard deviation, minimum, maximum, and coefficient of variation were used for analysis. The coefficient of variation was calculated as CV = standard deviation / mean.

8. Experimental Setup

The experiment was conducted on a local Windows 11 environment using PostgreSQL 18.6, MongoDB 8.3.8, and Python 3.14.6. The benchmark was designed as a single-machine controlled experiment rather than a distributed production benchmark. This distinction is important because distributed deployments, replication, sharding, concurrency, and cloud infrastructure can substantially influence performance.

9. Results

9.1 Bulk-Write Performance

Dataset	PostgreSQL Mean (s)	MongoDB Mean (s)	Faster
10K	0.450	0.079	MongoDB
50K	4.075	2.766	MongoDB
100K	7.936	1.292	MongoDB
500K	14.139	15.917*	PostgreSQL*

*MongoDB's 500K mean is strongly affected by a single 109.338-second observation; its median was substantially lower.

MongoDB was faster for the first three dataset sizes. At 100,000 records, its mean write time was approximately 6.15 times lower than PostgreSQL's. At 500,000 records, PostgreSQL had the lower mean, but the result requires cautious interpretation because of the extreme MongoDB observation.

9.2 Indexed Read Results

Dataset	PostgreSQL Mean (ms)	MongoDB Mean (ms)	Faster
10K	0.208	1.065	PostgreSQL
50K	0.677	1.382	PostgreSQL
100K	0.895	1.622	PostgreSQL
500K	0.632	0.871	PostgreSQL

PostgreSQL produced lower mean indexed point-read latency at every tested dataset size. At 10K records, PostgreSQL was approximately 5.1 times faster by mean latency. At 500K, the relative advantage decreased to approximately 1.38 times.

9.3 Variability Analysis

Dataset	PostgreSQL CV	MongoDB CV
10K	105.2%	102.4%
50K	118.0%	113.4%
100K	145.6%	105.5%
500K	105.5%	209.9%

Both systems demonstrated run-to-run variability in the write experiment. The largest instability occurred in the 500K MongoDB write experiment because of the 109.338-second observation. The read workload generally exhibited lower absolute variability than the write workload.

10. Discussion

10.1 Write Performance

The results indicate a clear MongoDB advantage in the smaller and medium-sized write workloads. MongoDB was faster at 10K, 50K, and 100K records. This is broadly consistent with recent controlled workload research reporting advantages for document-oriented persistence under write-intensive workloads [5]. However, the 500K result demonstrates why database performance cannot be summarized by a simple ranking. The extreme MongoDB observation substantially increased its mean, so the median and distribution of observations should also be considered.

10.2 Indexed Read Performance

The read results demonstrate a more consistent pattern. PostgreSQL produced lower mean latency at all four dataset sizes. The result is consistent with prior research showing strong read performance from indexed SQL configurations [5] and with research demonstrating the importance of indexing in PostgreSQL/MongoDB comparisons [2].

10.3 Workload Dependence

Taken together, the results indicate that the performance winner depends on the workload. MongoDB was generally faster for the tested bulk-write workload, while PostgreSQL was consistently faster for the indexed point-read workload. This agrees with the broader literature, which repeatedly finds that SQL versus NoSQL performance cannot be reduced to a universal ranking [1]–[5].

11. Answers to Research Questions

RQ1: MongoDB demonstrated lower mean bulk-write times at 10K, 50K, and 100K records. PostgreSQL had the lower mean at 500K, although the MongoDB result was strongly influenced by an extreme observation.

RQ2: PostgreSQL demonstrated lower mean indexed point-read latency at all four dataset sizes.

RQ3: Both systems demonstrated meaningful run-to-run variability in write performance, with especially high variability in some larger workloads.

RQ4: No. The results indicate workload-dependent performance rather than a universal winner.

12. Comparison With Existing Research

Study	Main workload	Main finding
Li & Manoharan [1]	Fundamental key-value operations	Performance varies by database and operation
Makris et al. [2]	Spatio-temporal queries	PostgreSQL generally outperformed MongoDB
Leung & Zhou [3]	Large Twitter datasets	Performance depends on workload and scale
Győrödi et al. [4]	CRUD / document-oriented data	Performance differs with operation and data volume
Pantelic et al. [5]	Read/write/mixed + concurrency	Indexed SQL strong for reads; MongoDB strong for writes
Present study	Bulk writes + indexed point reads	MongoDB stronger for most writes; PostgreSQL stronger for indexed reads

13. Practical Implications

For applications dominated by bulk writes, MongoDB may be attractive under workloads similar to those tested here, particularly at smaller and medium data volumes. However, production behavior should be validated because the 500K MongoDB experiment showed substantial variability.

For applications dominated by indexed point reads, PostgreSQL may be advantageous when fast structured-record lookup is important. These implications are limited to the tested workload and should not be generalized to joins, aggregation, transactions under contention, geospatial queries, or other workloads without additional experiments.

14. Limitations

·        Single-machine environment: the experiment does not directly represent distributed, replicated, sharded, or high-concurrency production deployments.

·        Synthetic data: real-world datasets may have more complex relationships, distributions, document sizes, and access patterns.

·        Limited workload types: only bulk writes and indexed point reads were tested.

·        Five repetitions per configuration: more repetitions could improve confidence in the estimates.

·        Extreme observations: the MongoDB 500K write experiment included a 109.338-second observation that materially affected its mean.

·        Resource monitoring: CPU, memory, disk I/O, and network utilization were not recorded, so the experiment measures performance differences without definitively explaining their system-level causes.

15. Future Work

15.   Increase repetitions from 5 to 10–15.

16.   Record CPU, RAM, and disk I/O utilization.

17.   Include update and delete workloads.

18.   Evaluate range, aggregation, and full-text queries.

19.   Compare indexed and non-indexed configurations.

20.   Evaluate concurrent clients and contention.

21.   Test datasets larger than 500,000 records.

22.   Repeat the benchmark on cloud infrastructure.

23.   Evaluate distributed, replicated, and sharded configurations.

24.   Investigate the cause of extreme observations such as the 109.338-second MongoDB run.

25.   Consider standardized benchmark suites such as YCSB where appropriate.

16. Conclusion

This research experimentally compared PostgreSQL and MongoDB under increasing data volumes using bulk-write and indexed point-read workloads. The results demonstrate that database performance depends strongly on the operation being performed.

MongoDB produced lower mean write times for the 10K, 50K, and 100K datasets. At 500K records, PostgreSQL produced a lower mean write time, but the MongoDB result was strongly influenced by a single extreme observation. For indexed point reads, PostgreSQL consistently produced lower mean latency across all tested dataset sizes.

The study therefore does not identify a universal winner. Instead, it demonstrates a workload-dependent trade-off: MongoDB showed an advantage for most of the tested bulk-write workloads, whereas PostgreSQL showed a consistent advantage for indexed point reads. The practical conclusion is that database selection should be based on application workload characteristics rather than an assumption that either SQL or NoSQL databases are universally faster.

17. References

[1] Y. Li and S. Manoharan, “A performance comparison of SQL and NoSQL databases,” 2013 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM), pp. 15–19, 2013. DOI: 10.1109/PACRIM.2013.6625441.

[2] A. Makris, K. Tserpes, G. Spiliopoulos, D. Zissis, and D. Anagnostopoulos, “MongoDB Vs PostgreSQL: A comparative study on performance aspects,” GeoInformatica, vol. 25, pp. 243–268, 2021. DOI: 10.1007/s10707-020-00407-w.

[3] F. Leung and B. Zhou, “Performance evaluation of Twitter datasets on SQL and NoSQL DBMS,” Web Intelligence, vol. 14, no. 4, 2016. DOI: 10.3233/WEB-160344.

[4] C. A. Győrödi, D. V. Dumşe-Burescu, D. R. Zmaranda, and R. Ş. Győrödi, “A Comparative Study of MongoDB and Document-Based MySQL for Big Data Application Data Management,” Big Data and Cognitive Computing, vol. 6, no. 2, 49, 2022. DOI: 10.3390/bdcc6020049.

[5] N. Pantelic, L. Matic, L. Jakovljevic, S. Eric, M. Eric, M. Stefanovic, and A. Djordjevic, “Benchmarking SQL and NoSQL Persistence in Microservices Under Variable Workloads,” Future Internet, vol. 18, no. 1, 53, 2026. DOI: 10.3390/fi18010053.

Appendix A. Experimental Summary

Item	Value
Databases	PostgreSQL 18.6; MongoDB 8.3.8
Operating environment	Windows 11, local single-machine benchmark
Language	Python 3.14.6
Dataset sizes	10K, 50K, 100K, 500K
Write repetitions	5 per database × dataset
Read repetitions	5 per database × dataset
Read lookups per measurement	1,000 indexed point lookups
Primary write metric	Execution time (seconds)
Primary read metric	Average lookup latency (milliseconds)
Variability metrics	Median, standard deviation, coefficient of variation

Appendix B. Benchmark Interpretation Notes

The benchmark is a controlled empirical study, not a universal ranking of PostgreSQL and MongoDB. Results should be interpreted within the specific dataset, workload, hardware, database configuration, and repetition strategy used in this experiment. No claim of statistical significance is made because inferential statistical testing was not part of the recorded experiment.

Appendix C. Verified Literature Sources

The five literature sources in the References section were cross-checked against publisher or scholarly records during preparation.

https://doi.org/10.1109/PACRIM.2013.6625441

https://link.springer.com/article/10.1007/s10707-020-00407-w

https://journals.sagepub.com/doi/10.3233/WEB-160344

https://www.mdpi.com/2504-2289/6/2/49

https://www.mdpi.com/1999-5903/18/1/53