I tell you what I'll do to make it easy for you Sebastian - I'll just remove my comments - and the post on my blogs with a link. That should keep you happy!! 

Nina

I would agree with Sebastian in that a lot of wrong terminology with portals gets used, and child portals mean two different things depending on who you speak to.

In addition, I often see statements saying that DNN stops working when you get to X portals.  A lot of people make the mistake of thinking of portals as separate little applications.  This isn't the case.  You should be thinking of a DNN install as being a single IIS/ASP.NET application : because that's what it is.  It's easy to get seduced into thinking two portals are separate because they look different, and you can't "see" any trace of the other portals when looking at any given portal : but it's all one big application.   There is very little difference between 20 portals x 10 pages each, and 200 portals of one page each.  Just a few more entries in the database portals table, and a few more directories created on the server in the portals/ directory.  You get a bit more overhead with each portal because of the 9 or so admin pages that get created with each new one, but that is exceedingly small fry in the overall application picture.  All the module code is only loaded once per DNN install, all of the core code is onlly loaded once per DNN install.

You will get far greater variance in performance and reliability from using the wrong settings or installing poorly performing modules than you will from creating too many portals.  And creating separate IIS applications will place just as much load on the server as combining portals : if not more.  For each DNN install, you've got to maintain a separate app pool, all with the DNN Framework loaded.

So choose your model of DNN usage based on the advantages/disadvantages of the shared/separate model based on management and database backup/restore scenarios.  Not on some magic 'you can only run 10 portals' figure.