iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Layerbase’s corrected YCSB test on one 4-vCPU, 8-GB machine, FerretDB 2.7 with tuned ZFS and PostgreSQL settings delivered roughly five times MongoDB 8.0.29’s read throughput and 3.3–3.8 times its throughput on a 50/50 read/update workload. Those are results for a specific, memory-constrained setup—not a universal ranking of the two databases. The test also changed FerretDB’s storage settings and discarded an initial round after finding three harness errors.
What did Layerbase compare?
Layerbase’s August 19, 2026 report describes a YCSB benchmark of MongoDB 8.0.29 and FerretDB 2.7, with FerretDB using PostgreSQL as its storage backend. It ran on a single Debian 13 machine with 4 vCPUs, 8 GB of RAM, and ZFS; ZFS’s ARC cache was capped at 2 GiB. The test used YCSB 0.18.0-SNAPSHOT, 10 million records, one million operations per run, and a 600-second run cap. The estimated dataset was about 10 GiB, larger than the host’s RAM. Layerbase’s report is the primary source for the setup and results.
| Benchmark element | Reported configuration |
|---|---|
| Host | 4 vCPUs, 8 GB RAM; Debian 13; ZFS with ARC capped at 2 GiB |
| Databases | MongoDB 8.0.29 and FerretDB 2.7 |
| Dataset and run | 10 million records; approximately 10 GiB estimated dataset; one million operations per run or a 600-second cap |
| YCSB | Version 0.18.0-SNAPSHOT |
| Client thread settings | 16, 64, and 256 threads; these are client-thread counts, not proof of the same number of simultaneous database connections |
| Write concern | 1 |
Which workloads were included?
| YCSB workload | Operation mix |
|---|---|
| C | 100% reads |
| B | 95% reads, 5% updates |
| A | 50% reads, 50% updates |
Because the estimated working set exceeded the machine’s 8 GB of RAM, memory pressure and storage behavior were central to this comparison. It represents one host profile, dataset size, and set of database configurations; it does not measure every deployment condition.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesWhy did the first benchmark round get discarded?
Layerbase says the first set of measurements was deleted after three problems were found in the benchmark harness. The published figures come from a corrected run, but the problems matter because they show how a benchmark can produce plausible-looking labels that do not match what it actually measures.
#1 Best Overall
The thread setting did not take effect
The YCSB command used threads instead of the option YCSB reads, threadcount. As a result, runs labeled with higher thread counts silently ran with one thread.
The connection pool did not match the 256-thread label
The MongoDB Java driver’s default connection pool size was 100 unless mongodb.maxconnections was set. Therefore, a run configured for 256 client threads should not be interpreted as 256 simultaneous database connections. Layerbase reports thread counts, not a claim that all those clients held concurrent connections.
The output parser missed throughput
A regular expression in the CSV extraction script used unescaped parentheses and matched no throughput output. That made the first round unusable as a source of absolute published numbers. The author says those results were discarded rather than presented as the final benchmark.
Recommended Free Tools
What changed in the FerretDB and PostgreSQL setup?
Layerbase found a mismatch between ZFS’s 128 KiB default recordsize and PostgreSQL’s 8 KiB pages. In the report’s explanation, writing an 8 KiB page into a 128 KiB record can require a read-modify-write of the larger record. The author tested a 16 KiB ZFS recordsize. The report also found PostgreSQL’s shared_buffers at its 128 MiB stock default on the 8 GB host and tested scaling memory settings with the hardware. It does not specify the exact tuned memory values in the evidence summarized here, so those should not be inferred.
What the separate tuning tests showed
Layerbase ran an ablation—tests intended to isolate the effects of changes—rather than treating the combined tuning as one unexplained adjustment. The reported results were:
| FerretDB setup or comparison | Reported result | How to read it |
|---|---|---|
| Memory tuning alone, with the 128 KiB ZFS recordsize retained | About 1.0× on reads; it could be negative at 256 threads | The author attributed the high-thread result to checkpoint pressure. |
| 16 KiB ZFS recordsize alone | 3.7×–4.3× on reads | Reported against the ablation control. |
| 16 KiB recordsize plus memory tuning | 4.0×–4.3× on reads; 2.4×–3.0× on the 50/50 read/update workload | Reported against the ablation control box. |
The combined ablation comparison is not interchangeable with comparison against the earlier stock arm: Layerbase says the boxes for those arms were built on different days. The report’s ablation therefore helps show why its own FerretDB defaults mattered, but the results should not be collapsed into a single, directly comparable multiplier.
What were the headline results?
For the specified 4-vCPU, 8-GB profile, Layerbase reports that tuned FerretDB achieved roughly 5× MongoDB’s read throughput and 3.3×–3.8× MongoDB’s throughput on the 50/50 read/update mix. These are the report’s approximate relative throughput figures for its corrected YCSB runs—not absolute operations-per-second figures or a guarantee for other workloads. Layerbase also says untuned FerretDB was roughly at parity with MongoDB on the mixed workload, and attributes much of the tuned result to correcting its own storage defaults. See the benchmark report for its measurements and configuration details.
What the benchmark does—and does not—establish
It is a memory-constrained single-machine case study
The estimated 10 GiB dataset was larger than the 8 GB host’s RAM, so the result reflects this particular pressure on memory and storage. Layerbase cautions that the gap may narrow, and the ranking could change, when the working set fits in memory. The report does not establish which database is faster across other dataset sizes, hardware, filesystems, workload mixes, or settings.
It does not compare MongoDB at the other reported machine sizes
Layerbase also reports 64-thread tuned-default FerretDB results on dedicated 4-GB and 16-GB machine profiles. Those profiles ran FerretDB only, without corresponding MongoDB arms. The roughly 5× and 3.3×–3.8× MongoDB comparisons cannot be extended to those machines.
Rank #4
It did not benchmark Atlas or equivalent architectures
The report’s setup is a dedicated single-node profile. It did not benchmark Atlas, and a single-node server is not architecture-equivalent to Atlas replica-set tiers. Separately, Layerbase notes that a third-party billion-record result in which MongoDB wins writes applies to that different scale and setup; it is not a direct contradiction of this smaller test.
Performance and application compatibility are different questions
Throughput results do not establish that an application can switch databases without changes. FerretDB describes itself as compatible with MongoDB drivers and popular tools, and says it works as a drop-in replacement in many cases. Its project repository also documents known differences and supported commands, so check the needs of the particular application rather than assuming benchmark performance proves feature compatibility. FerretDB’s repository documents compatibility information.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How should readers judge or repeat a database benchmark?
A useful benchmark is more than a pair of throughput numbers. MongoDB’s engineering guidance describes an iterative process: model a real phenomenon, measure, analyze, repeat to check whether results recur, and change one variable at a time. That is methodological context, not an independent reproduction of Layerbase’s figures. MongoDB’s article on reducing performance-test variability explains that approach.
For a replication or a decision about your own workload, record the variables that can change the outcome:
- Database versions and whether the comparison is single-node or replicated.
- Hardware, operating system, filesystem, and storage settings.
- Dataset size and its relationship to available RAM.
- Backend-specific memory, cache, and checkpoint settings.
- Read/write mix, durability settings, client-thread count, and actual connection-pool limits.
- Harness version, exact workload options, output parsing, and whether repeated runs produce similar results.
Layerbase reports an ablation and says it discarded the flawed initial harness generation. The exact corrected figures have not been independently reproduced in the cited material, so they are best treated as the publisher’s reported results for its disclosed setup rather than an independently verified ranking.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
