Node info is stored in ezcontentobject_tree it's primary_key is stored at int(11) so this will be the number of nodes the system will support (well within 20,000 :).
However it's the a ezcontentobject_attribute table that will cause problems before you run out of nodes. It's primary keys is also int(11) and you ususally have multiple attributes per content_object not to mention versions.
Assuming that php will handle ints of this size your site will have to have quite a few objects/nodes before you run into these limits.
Be good to get some definative upper limits from eZ though.
It would seem to me that those ints are rather theoretically hard upper limits. Much more important would be data about scalability. I doubt you'll be able to hold 32bit int worth of atttribute data (that'd be 4billion plus records) without choking the system much sooner. FWIW, ez.no seems to currently be at about 105000 contentobjects, so 20000 should be well within reach on appropriate hardware.