First, it is my strongly held opinion that documents do not belong in a
Portal, only Listings. "You don't go to an Internet portal  (like Google,
MSN, Yahoo) to find documents on that portal, you go to an Internet
portal to locate documents located elsewhere that have been indexed or
categorized by the portal". SharePoint Portal Server is no different.

Second, 500 GB will benefit from two or three dozen content databases to
be manageable. I've heard that content databases get very unwieldy when
they grow larger than ~20GB but I've heard of people with content
databases in the 300 GB range. They were complaining but the database
allowed it. Remember, each site collection must be managed in a single
content database.

Third, SPS alters the way that security works, its intent is to have
thousands of readers and very, very few contributors. Portals are not
designed for collaboration, team sites are.

Fourth, backup and restore will be a real pain.

Fifth, navigation will suck.

Sixth, migration from v2 to v3 will be more challenging than it would
otherwise be. The smallest scope of migration will be a site collection.

Seventh, WSS is way easier to customize than SPS.

Probably a dozen other reasons for why you should consider using WSS
site collections for your solution and putting a portal in place just
for the reasons that demand a portal.

What SPS capabilities do you need in your solution? If you don't need
portal, you should strongly consider using WSS.

If your primary objective is usability, I highly recommend a WSS oriented
solution. Subdivide your data into unique site collections leveraging managed
paths, Webs, Document Libraries, Lists, and folders as repositories, event sinks
for workflow, alerts for communication, and Library-level security (something
you will not have in SPS) to protect the documents; but present only one
homogenous front end to the Information Worker to consume and collaborate within
your structure.

WSS is a platform, SPS is a product. A platform can be flexibly consumed and can
conform to your business needs whereas a product is to be used as designed and
has significant limits to its customizability,. For example, trying to extend
SPS Listings or the SPS Grouped Listing Web Part is futile. Contrast that with
WSS Link lists and the DVWP which are extremely flexible.

What SPS-only feature(s) lead you to conclude that you must implement your
solution on top of the SPS product rather than exploiting the WSS platform
directly? I assure you, trying to implement this solution using SPS will extend
the time it will take to complete the project and you will sweat bullets much
bigger than needed.

we are planning to use a 3rd party tool like avepoint for recovery. so i hope
these tools are dont have too much of a problem recovering this size  of data..

the reason we using only portal  is mainly for user acceptance reasons. we are
migrating the content from a folder orientated system and want to give the user
a similiar look and feel. mainly the navigation paths shouldn't change. The old
system has permissions on folder level. these also have to bee retained..