i.e. the only code which knows that the profile is in the db for a user is the accessor which fetches it and makes it available to the rest of your site and the creation/update code which stores it.

Then you can change your mind later by:

1. add a new column (profile_filename) to your table
2. change your accessor to use profile_filename (if present) or the old column if not
3. change your profile creation code to save as a filename
4. run a batch job to create filenames for all profiles still stored in the db, populating the new column
5. drop the old column and remove the backward-compat code from your accessors.

Also, you might find that you end up wanting your profiles in the db. If you need to scale, sometimes the best way is to replicate your back-end storage. If you're storing in more than one place (db and filesystem) you've complicated the process by which you do that.

Make sure you look into indexes at that volume. They will improve performance a lot if you implement them correctly. Do your homework though because they can degrade perfromance if you don't use them correctly.

If you are really concerned about growth, put the profiles in a separate database from your session table, etc. That way you can move it to another machine someday without rewriting.

Does it matter? Well not right now, not until you have the community setup.

Once things are up and running though performance would almost certainly be better if you were using a database - since you'll be wanting to display things like username, last login tim, profile details, etc.

It just makes sense to me to use a database - especially because I'm assuming you'll have to store login names and passwords anywhere. A database is designed to get fast at queries and to link things together.

Maybe something simple will get you started, something like this:

CREATE TABLE `users` (
  `id` int(11) NOT NULL auto_increment,
  `username` varchar(25) NOT NULL default '',
  `password` varchar(32) default NULL,
  `email` varchar(75) default NULL,
  `joined` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`id`),
  KEY `username` (`username`)
);

CREATE TABLE `user_info` (
  `userid` int(11) NOT NULL,
  `profile_text` TEXT default '',
  `location` varchar(30),
  `age` int default 0,
   ...
   ..
);

CREATE TABLE `user_preferences` .. ;

CREATE TABLE `user_friends` ... ;
[download]

Then you can run a simple query to get the profile text, age, etc, from the user_info table, and all the other details from any other tables you might create.

How much is too much for a database is sensitive to a number of factors, including the database engine, the O/S, and the hardware it's running on, so there's not an answer to "is it bad to have one database store that much info?" without considerably more information. I would not consider a table with 5,000,000 entries to be unacceptably large, but the bulk of my DB experience is as a user, querying a DB2 database via an API (the database stored, among other things, the drawing and manufacturing document data for a very complex manufactured artifact).

If you're seriously worried, get a DBA to help you layout the DB system.