Hi Ivan,
I am not sure how scalable is the content repository (CR) on large files but so far it is ok for our use. The CR can either use the file system or the database to store the binary files. Using the file system seems to be more appropriate with large and many files. So what is stored in the database is just the file name and path. All the files are stored in acs_root/content-repository-content-files.
I am not familiar with the photo-album package but ETP, CMS and file-storage stores the filename in the table cr_revisions at column content. Setting the cr_revisions.storage_type to "file" and some other tcl api stores the file in the file system, look at how file-storage does this. The storage of the binary files should be scalable since it just putting the filename and path on the db. The fetching of the file is done via the Tcl api cr_write_content. The code looks pretty straight forward but if there is a bottle neck it may arise from fetching the images. After all I would assume that there are more readers than writers. Don B wrote the tcl api cr_write_content he should have a better opinion regarding its performance, as for me I am happing with the Content Repository. I use it for practically everything that I need to store binary files when extending other apps.
