We want to build a image database driven website. Visitors will trigger searches resulting in pages that roughly resemble Goggle's Image search results page: <http://images.google.com/images?q=cars> As in Goggle a click on a thumbnail will lead to a page with a <single view> of the picture (max 600 px wide). If the original still is bigger, there might be a link to a full-size view. The database will hold 8,000 - 10,000 pictures for a start, most of them small gifs. Image types will mostly be GIF and JPEG. Every image needs a <thumbnail>, a <single view> and a <full view>. Also there should be all kinds of metadata (jobs we used it for, creator, date of creation, keywords, description, notes, etc) Now the ?'s: If we chose to use the ZODB, how should the images with all their thumbnails and metadata stored for fast access? What would be the best strategy? Create some kind of object (folder) containing the thumbnails and metadata for each single image? Or better separate the thumb's from the original image? Or just dump everything into the same BTreeFolder? And would ZODB be fast enough? Or are there better solutions if speed matters? Lalo described they use PostgreSQL but if possible I'd like to keep everything inside Zope (maybe place the bare image files in an external file system). Might it make sense to generate the thumbnails on the fly when requested? So we only have the "original" files in the database (I guess not if speed we need). Is the property of a picture the right place to store the metadata? If so I'm not really sure what to do if I create a new property called "client" but the values could be many at the same time (Nike + Adidas + Puma) for a single image ... how will this be handled? thanks for any answers! 'K:?