Non scientific database performance comparison between Freebsd and Linux

On the same hardware , SSD-Disks. On one side Freebsd with ZFS filesystem, and on the other side Arch-Linux with XFS filesystem.
Number of transactions per second comparison:
Tokyocabinet-DB was 50% faster on Linux
Redis-DB was as fast on Linux as on Freebsd
Mongo-DB was 20 % faster on Freebsd
Postgresql-DB was 30% faster on Freebsd
Sqlite-DB was 3X times faster on Freebsd

For FreeBSD on ZFS I had:
Tokyokabinet : 520.000 transactions/s
Redis: 22.700 transactions/s
MongoDB: 2000 transactions/s
PostgreSQL: 800 transactions/s
SQLite: 333 transactions/s
 
Running on top of file systems? With SSD or spinning disk? Wouldn't surprise me if the big difference is in the underlying storage layer.

A lot depends on how the database implements writing to disk, and how things are configured. For example, one database might update blocks (or pages) very quickly, and with sync writes. Another might first log changes in an on-disk (sequential append) log for minutes at a time, and then update the data pages in bulk and non-synchronous. So differences in implementation of write caching, random versus sequential, and how sync is done, can have outsize influence on database performance.
 
MongoDB: 2000 transactions/s
PostgreSQL: 800 transactions/s
I think you made a mistake with either PostgreSQL or mongoDB.

Performance Benchmark: PostgreSQL vs. mongoDB

mongoDB vs PostgreSQL: A comparative study on performance aspects
The evaluation is based upon real, business scenarios and their subsequent queries as well as their underlying infrastructures and concludes in confirming the superiority of PostgreSQL in almost all cases with the exception of the polygon intersection queries.

PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE
A more realistic image of PostgreSQL performance were provided by read write (TCP-B) benchmark. Among the GNU/Linux distributions, Centos 7.4 was the best performer, while Debian 9.2 was slowest. I was positively surprised by FreeBSD 11.1 which was more than twice as fast as the best performing Linux, despite the fact that FreeBSD used ZFS which is a copy-on-write file system. I assumed that such a difference was caused by the Linux software RAID overhead, so I did three more TCP-B benchmarks for 100 concurrent clients, this time without software RAID. These results show the inefficiency of the Linux SW RAID (or ZFS RAID efficiency).

You can say that PostgreSQL is generally the best and most powerful database of 2023 for most situations.
A nice thing to know is that PostgreSQL was originally developed primarily for FreeBSD.
 
If I ask a developer what percentage of the time they think the database will be writing (vs reading), I'm invariably told numbers like 20 or 25 percent. In fact, I remember having a discussion with a SQL Server product group member who was writing an MSDN whitepaper and I was a reviewer. He told me that he thought 40 to 60 percent was common.
But every time I measure this for these types of applications, and over a lengthy period, guess what write percentages I normally see?
Less than one percent is common and 1 or 2 percent is quite typical.
I'm going to focus on what the system is doing 99 percent of the time, not so much on the 1 percent, unless the writes are particularly time critical for some reason.
And the wonderful thing is that if you reduce the impact of the reads, the system has more time to work on writes anyway.
Reducing the impact of reads will generally improve the performance of your writes.


A comparison of latency for MongoDB and PostgreSQL
As presented above, the benchmarking results for the Read operation for MongoDB was slower in the experiments of this study compared to PostgreSQL.

Is the performance of $lookup still 130 times worse than Postgres?

PostgreSQL vs MongoDB
+-------------+-------------------+--------------------+
| Benchmark # | PostgreSQL | MongoDB |
+-------------+-------------------+--------------------+
| query 1 | 8349 microseconds | 21721 microseconds |
+-------------+-------------------+--------------------+

Those Who Forget the Past Are Doomed to Repeat It
Forty-five years later, this conclusion is still true. If you want to insulate yourself from the changes that business conditions dictate, use a relational DBMS.
If you want the successor to the successor to your job to thank you for your wise decision, use a relational model.
 
I feel obligated to point out that the comparisons in this thread are distinctly lacking in mentions of MySQL and MariaDB! That said, Postgres is a very wonderful database system, so is a good representative from the SQL/relational camp.

I'm not sure it makes that much sense to compare a document store such as MongoDB to relational/SQL systems (or "object-relational" in the case of Postgres) since they have somewhat different capabilities and therefore cater better to different sets of use-cases - although there is also some overlap, of course. In any case, I think it's difficult to design meaningful benchmark comparisons between these systems. E.g. joins are the bread-and-butter of relational databases whereas if you ask MongoDB to join 20 collections it will probably not be very happy. On the other hand, JSON documents are first-class citizens in MongoDB, so it can probably out-do relational database system when it comes to operations on those.
 
I'm not sure it makes that much sense to compare a document store such as MongoDB to relational/SQL systems (or "object-relational" in the case of Postgres) since they have somewhat different capabilities and therefore cater better to different sets of use-cases - although there is also some overlap, of course.
I have a basic knowledge of mongoDB since I have taken training for this database. My impression is that mongoDB has enough capabilities to replace a SQL database in most situations, purely in terms of features then. But I don't think mongoDB has many important features that are not present in PostgreSQL.
What I mean by this is, you're not going to choose mongoDB 99% of the time because it has some important feature that PostgreSQL doesn't have. A few quotes to illustrate this:

The conclusion is pretty surprising as there isn’t really anything that MongoDB can do and PostgreSQL can’t.
PostgreSQL also outperforms or at worst, matches MongoDB for performance.


O'Reilly Media - PostgreSQL: Up and Running, 3rd Edition
PostgreSQL bills itself as the world’s most advanced open source database. We couldn’t agree more.
Perhaps more importantly, we highlight feats you can achieve with PostgreSQL that are difficult or impossible to do in other databases.
Each day you continue to use a database with limited SQL capabilities, you handicap yourself.


Postgres - The first experience
PostgreSQL is the most feature-rich free open-source data-base system.
Nowadays, PostgreSQL offers everything that most customers need, and it is actively used all over the world to create high-load business-critical systems.


I think the reason why mongoDB is popular is similar to why Python is popular. Many persons learn (only) what they are taught in school and beyond that, many developers do not have the skills or eagerness to learn other things needed to gain the most useful knowledge.

NoSQL databases have grown in popularity over the last decade because they allow users to query their data without having to learn and master SQL.
Last but not the least, more than a generation of developers have struggled with SQL and its several variations. The promise that one does not need to learn and master SQL to extract data from the database but can rather do it using Javascript or other more developer friendly tools is just too exciting to pass on.


I feel obligated to point out that the comparisons in this thread are distinctly lacking in mentions of MySQL and MariaDB!
Benchmark databases in Docker: MySQL, PostgreSQL, SQL Server
Plus MariaDB, Percona and TimescaleDB
The conclusion of this benchmark is that MariaDB and MySQL have not been competitive with PostgreSQL in terms of performance for some time.

On the other hand, JSON documents are first-class citizens in MongoDB, so it can probably out-do relational database system when it comes to operations on those.

That's not really the case. mongoDB can't out-do most SQL databases in JSON.

e650074700b34ebcb9556206e18b7de3.png

36ff0aa24e3d4d449711c2a93790a3b0.png


4bc93e1c29a24f2ea3c31a54f5c92474.png

e42e052618da4301bff5bab12a6bfe48.png
 
MongoDB vs. Postgres Benchmarks / Álvaro Hernández (OnGres)
View: https://www.youtube.com/watch?v=-AIjKrWi0x0


Here you see another professional benchmark where mongoDB is very slow compared to PostgreSQL.
However, this is not the whole story:

Benchmarking: Do it right or don't do it at all

The Data-Based MongoDB vs. Cassandra Study (2022)

Benchmarking between kong with cassandra and postgres

Database performance comparison for IoT use cases

If you are a beginner then from the above two benchmarks you are going to think PostgreSQL is really faster than Cassandra.
But if you are an expert then you know Cassandra has more than 100 options to tune the performance. The same is the case for PostgreSQL.
It is also true that JOIN operations are usually slow on SQL databases, while Cassandra is put together in a way to make this go lightning fast.

Another research:

Here we see that Cassandra is faster than PostgreSQL for insertion, but slower for extraction. And mongoDB is the fastest of the three databases in the above test for the two tasks.

Based on the industry-standard benchmark created by Yahoo! called YCSB, MongoDB provides greater performance than Cassandra in all the tests they have executed, in some use cases by as much as 25x. When optimized for a balance of throughput and durability between Cassandra and MongoDB, MongoDB provides over 50% greater throughput in mixed workloads, and 2.5x greater throughput in read-dominant workloads compared to Cassandra.

Cassandra considers performing better in applications that require heavy data load since it can support multiple master nodes in a cluster. Whereas, MongoDB will not be ideal for applications with heavy data load as it can’t scale with the performance.

Benchmarking Top NoSQL Databases

Then again, in the last link you can see that mongoDB is not remotely competitive with Cassandra in terms of performance.

We can conclude that the idea people have about which database is the fastest is similar to religion. Large groups of people have fundamentally different views.

Of course, both groups cannot both be 100% right. What you see is that there are persons who are completely convinced that they are smart enough to make sensible statements about this domain, but in reality their knowledge is not sufficient to make any useful statement.

And it's ultimately just what you believe.

It would not surprise me that 90% of the data administrators and data engineers currently active do not have the required knowledge needed to choose the most suitable database for their specific workload. Nor have they done any benchmarking of different databases.
 
The first question a database developer should ask is, of course, which programming language is best suited to develop this sophisticated app.
If you and your team make a poorer decision there, your database is going to have a significant disadvantage over certain other specific databases.

When is java faster than C++?

In almost 20 years of C++ and Java development, my impressions are exactly the same: the bigger the program, the more concurrent, the harder it is to beat Java.

If you go and ask most 'developers' whether Java or C++ is faster, most will say C++ performs faster.
But the basic knowledge that most developers miss is that if you give Java enough RAM, it can be faster than C++ in many situations.
 
Cassandra was not included in the original test but it normally is a database that gives very strong performance if you configure everything optimally.

2023-08-29-165434_1920x1080_scrot.png

2023-08-29-165510_1920x1080_scrot.png

As we can see, mongoDB is many times slower in these two tests.

Cassandra is also in terms of features a powerful database. And CQL is very similar to SQL, it is almost exactly the same.
 
Back
Top