I'd say to do whatever is easiest for you right now (which is probably the db route) and localise the knowledge in your code.

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.

Which looks like a lot of work in a list, but isn't that much, really.

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.