For a social Website each user is going to have a photo album. I realized I don't really need a database for the images, they can simply be organized in folders, so one would do something like (pseudo-code):
$photos = files("albums/$user_id/*")
foreach($photos as $photo)
img($photo);
Other articles I've read says that file operations like file_exists() are very quick, so there is no point in worrying about them, and this article says you can scan folders very quickly.
I don't need any metadata or other data to accompany the images, so the only purpose the database would serve is tell me which images a user has, but I can get that information by reading the directory, and I only need to show one album per page load. I have no need to do any sort of database queries on the images either.
I'm just a bit curious since I've always organized image files in database tables, if there is any huge disadvantages from going away from using database tables, performance-wise or otherwise?
file_exists() is only "quick" as compared to other disk I/O operations, and it will only be "quick" on small directories. If you happen to start getting close to the 1000 item mark in any given directory you will find that "quick" becomes "painfully slow".
As well, using file/folder-based operations completely throws parallelism out the window as there is only one read/write head to find those files, and anything else the server needs to do is either on hold while you scan directories, or puts your operation on hold while it completes.
So yes, technically just using files/folders is probably just about as fast as using a database, provided it's just for a handful of users with a handful of files on a server that isn't particularly busy at any given time.
Using a database you will have the benefit of parallelism, indexing, and caching, all of which will easily scale with the level of activity in your application provided your schema and indexing strategy are sound.