In the previous blog posts, I said Drupal is more robust than WordPress in 2020. For some of you, that can be a surprise. Let's see why Drupal's data structure makes it more performant than WordPress.
Modern content management systems (CMS) usually store their content in a database. Usually in MySQL. To understand why Drupal is more robust than WordPress in storing data, we need to have a basic idea how the database works. A database is basically a set of tables. Yes, like an Excel file. There are tables for users, with columns for an id, name, email, password hash, and there are tables for content, for tags, for files, etc., each having table structure befitting it's purpose. When you work with content, data is searched, read, and written into the database, in the corresponding tables.
The problem of WordPress here is that it's a glorified blog platform, that expects in it's architecture to have only blog posts. When support for new post types is added by a third-party plugin, no new table is created. The new post types are expected to have custom fields, and there is no support for this in WordPress either, which ends up in different post types and their fields being squished into the original two tables intended for the blog posts.
Now, if you look at the picture for this blog post, you will see the problem that WordPress has there. It only has two tables to store content. One, wp_posts, stores the post content, and the other, wp_postmeta, stores... well, everything else content - like field values, post metadata, etc. And that table is thus bloated. So, if you have different post types, and different fields, there are no special tables provided for it, and it's all messed up in a single wp_postmeta table, making it slow and hard to manage.
There is another problem in all this. Different fields need different columns to work store it's data, so it's either creating more and more additional columns in the database, or trying to "pack" the content to fit a single pattern. WordPress chose the latter. On another image above image you can see some values in wp_postmeta table having a weird "encoded" look. It's called "serializing", when the information is "packed" in a single string. It allows to add the disperate information into a single table, but it also makes it slower, because MySQL can not search and query inside that packed data.
This is the weakness in WordPress, this is where performance and architecture is sacrificed to continuity. On the other hand, Drupal has a separate table for each field, allowing flexibility and scalability that WordPress with it's data architecture can not provide.
Now, you will ask, how critical is this database architecture issue for WordPress performance? The answer is, the issue exists, but it's not critical, not even really bad for small blog sites. If you have a small WordPress site, and it loads in 500 milliseconds against the Drupal's 350 milliseconds - you won't probably even notice. These numbers come from my experience of testing WordPress 5 against Drupal 8 on multiple occasions - it usually boils down to around 15% - 25% difference. That is why for most cases, it's not a critical issue. However, if your site grows big, and starts adding different content types, various fields, and needs to scale - then this increasingly becomes a problem.
So - this may not be a big deal to you in some cases. Its just one glimpse into why and Drupal is mostly more robust and performant than WordPress is. The funny thing is that if you are purely running a blog, without additional fields and additional content types (that's what WordPress was built for), then in this case this it's database architecture may actually be more robust that Drupal's.