Every once in a while one of our clients asks us if there is a maximum number of articles/categories/users on his Joomla website – and if there’s a maximum, then what is it.
Our answer is that there is a maximum, but there’s no way for that maximum to be reached in a single lifetime. The reason why we say this is that the type of the id of the article/category/user determines their theoretical maximum, which is in the billions. Let us give you more insight…
The id of the article in the jos_content table (jos has been replaced with a random 4 letter string in newer versions of Joomla to prevent hacking) is of type unsigned int(10) (unsigned means that we don’t need to reserve a bit for the + or – sign), a value that can hold 232, which means that you can have 4,294,967,296 – 1, or 4,294,967,295 (over 4 billions articles – we are subtracting -1 to account for the article with the id that equals 0, as the first article in Joomla has an id that equals 1 – the same goes for the categories and the users). Note that if the id field was a signed int, then this means that the maximum number of articles would’ve been 2,147,483,648 – 1 or 2,147,483,647 articles.
The id of the categories in the jos_categories table (same comment about the jos prefix as above) is of type int(11) . This means that the maximum number of categories is 232 (again, there is no need to subtract -1 from 32 as unsigned integers are always positive), which means that you can have up to 4,294,967,296 – 1, or 4,294,967,295 categories. (over 4 billion categories)
The id of the users in the jos_users table is of type int(11), meaning that the maximum number of users in Joomla is 232, or 4,294,967,296 – 1, or 4,294,967,295 users. (over 4 billion users)
In short, Joomla can have a maximum of about 4.3 billion articles, 4.3 billion categories, and 4.3 billion users! Impressive, isn’t it?
Now, let’s assume you’re creating the next Facebook by using Joomla: a website that has the profile of, let’s say, 4 billions persons – can that be achievable in Joomla? Technically, it can – but realistically, it can’t. This is because Joomla doesn’t scale well for even a fraction of that number as Joomla’s core is written with functionality, and not efficiency, in mind. A Joomla website, with a standard core, can possibly handle tens of thousands of users – but if you need more than that then you will need to modify its core.
Now, what if (ahem!) you reach any of the above limits, well – all you need to do is change the type of the id field in the table where you hit the limit from int to unsigned bigint (which means that the limit will be 264 or 18,446,744,073,709,551,616 – 1). You will also need to make the same changes to the type of the fields pointing to that id in the related tables – for example, if you change the type of the id of the user to bigint, then you will also need to change the type of the checked_out, the created_user_id, and then modified_user_id in the jos_content to bigint (note that there are other related fields where you need to make the change, but we’re just giving those as an example).
If you need help overcoming any of Joomla’s limitations, then we can definitely help (we are experts in customizing Joomla!) . Just contact us and rest assured that we’ll do exactly what you want in as little time as possible and for a very reasonable price!
When you said ‘can possibly handle tens of thousands of users’ does it mean active users? Or total registered users?
Hi Webchun,
Please note that this post is really, really old (from 2012). Having said that, we mean in the post registered users. By active users, I assume you mean visitors – a Joomla website residing on a decent server can handle a few thousand visitors/day without core modification.
If you mean active registered users (e.g. registered users browsing the website all at the same time), then it’ll be hard for Joomla 3.8.5 to handle thousands of registered users simultaneously without core modifications. This is because some caching features are disabled for registered users, and so the database load is generally heavier as more queries are executed to serve each page.