Should I use MySQL blob field type?

Is there a performance hit with using MySQL blob field type?

Not inherently, but if you have big BLOBs clogging up your tables and memory cache that will certainly result in a performance hit.

The other obvious route is storing the data in a specific folder structure outside of the webroot. in this case I'd have to come up with a special naming convention for folders/files to keep track of what they reference inside the database.

Yes, this is a common approach. You'd usually do something like have folders named after each table they're associated with, containing filenames based only on the primary key (ideally a integer; certainly never anything user-submitted).

Is this a better idea? It depends. There are deployment-simplicity advantages to having only a single data store, and not having to worry about giving the web user write access to anything. Also if there might be multiple copies of the app running (eg active-active load balancing) then you need to synchronise the storage, which is much easier with a database than it is with a filesystem.

If you do use the filesystem rather than a blob, the question is then, do you get the web server to serve it by pointing an Alias at the folder?

• + is super fast
• + caches well
• - extra server config: virtual directory; needs appropriate file extension to return desired Content-Type
• - extra server config: need to add Content-Disposition: attachment/X-Content-Type-Options headers to stop IE sniffing for HTML as part of anti-XSS measures

or do you serve the file manually by having a server-side script spit it out, as you would have to serving from a MySQL blob?

• - is potentially slow
• - needs a fair bit of manual If-Modified-Since and ETag handling to cache properly
• + can use application's own access contro