I want to design a member login site in WP but I have a doubt that is WordPress can handle more than 40000 users on same database?

I am not sure about this so I am stooping my work here. So please help me if anyone know exactly about this to proceed my project with WP.

According WP database structure, ID in wp_users is Bigint(20) UNSIGNED, so you could "theoretically" add 18446744073709551615 users. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

I think you can run even more users. The only thing that can limit you is your server. You'll have to scale it properly, especially MySQL server. For example wordpress.com runs even more then 40000 users, but they use extra powerful systems for stability, tons of load balancers and etc.

A bit late to answer this, but since its coming up for relevant search, this will be of use to somebody :

WordPress uses EAV database schema for part of its database implementation. This affects both the data, and users. (They are kept in separate tables)

To explain it from data angle:

Along with the directly accessible post related details in wp_posts, numerous meta is posted to wp_postmeta table for each post. Any data relevant to the post (or custom post type).

Problem with that is, if you have HEAPS of posts or pages (or custom post/data), it becomes quite slow to search for any property that is found in meta. You first search all the entries in meta table for the criteria you need, then get the relevant post from the table. The kicker is that you need to search for EACH criteria separately. So one search for tag, you get the posts with the value X for 'meta1', then you search for second criteria, say, customcriteria and get post ids with customcriteriavalue1 in customcriteria, AND then take the intersection of these and then go to get the post details from posts table with that intersection.

As an example - put 30,000 products into WooCommerce, and you will end up with ~1,800,000 rows in wp_postmeta as explained in below answer:

Post meta vs separate database tables

So, not only this will make searching very very inefficient (especially when you do self joins on wp_postmeta for multiple criteria), but also even querying a single row from among 1,8 mil rows does cause a performance hit.

EAV schema deficiency.

So with a lot of posts, WordPress db implementation makes complex searches very slow.

Running a WordPress site with thousands of posts is quite doable, if you use caching plugins. You can go even more. But the searches will be a problem.

............

Its the same with users too - wp_usermeta uses the same EAV format as well. So if you get a lot of users, and have a lot of plugins that store various user data in wp_usermeta, you will take the same performance hit.

Not to mention with so many users its likely that you will have a high number of posts already - unless your app is something that has to do with users mostly (CRM etc), and you choose to store your user data in wp_usermeta instead of wp_postmeta. (Unlikely though).

.........

There are some plugins which try to go around this issue, like Meta Accelerator.

https://wordpress.org/plugins/meta-accelerator/

This plugin takes any data for any given post type you choose and puts them in flat tables. This speeds up searching a lot, and it also speeds up querying any singular value.

But that plugin is in its infancy yet.

Alternatively, you can install ElasticSearch in the server and use ElasticPress plugin or another plugin that integrates it to WordPress to speed up such searches.

I've found the bottle neck for how many Wordpress users you can have is the PHP timeout coming into play on the users admin page.

Assuming all your users have at least 1 role they have a wp_capabilities entry in the user_metadata table with a serialized array of roles.

The admin page shows a count of how many users with each type of role there are so it has to load every single wp_capabilities serialized array, unserialize that and then show a total count.

When I have 300,000 users the users admin page takes 44 seconds to build.

This means each user adds 0.00014666666 seconds to the page load time.

Assuming your PHP timeout is 60 seconds that would put the limit at around 400,000 users.

However I am running a quite old and slow server. Faster hardware would improve things greatly.

  • I don't think the impact is linear but I agree with the gist of it, it is not so much the number but what you actually use the info for and where/when you access it – Mark Kaplun Aug 30 at 13:33

The question should be how many users can php-mysql stack handle instead of WordPress as WP is developed on those 2 principal technologies.

Being said that, if you can configure server with advanced server techniques, host WP in a good managed server, optimized database load and queries then WP can handle as many members as you want.

If you install wordpress in a shared hosting, then you are limiting your WP capability. On the other hand if you can manage youself running WP from a cloud based or dedicated hosting server then you should gain the desired result.

Wordpress is capable of handling complex database quarries. You can check out this https://codex.wordpress.org/Installing_WordPress

Also using wordpess as an advanced application development framework enables u making ur install to handle big/complex database load.

you can also chk this series: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Hope this will help. thanks

  • For the record, the PHP portion of the stack won't be your issue (Facebook is built with a modified PHP), but MySQL very well could be limiting. – Dan Apr 15 '14 at 11:13

protected by Community Oct 11 at 8:42

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.