> It seems to me as such a database gets larger, it will become much harder to manage with the 2 systems. I am talking mostly about music. So each song should not get too large. I was just talking about points to consider in general. Getting to your specific situation... As far as BLOBs vs. file pointers. Test it out, use what you're most comfortable using. I would not set up a networked file system for the sole purpose of managing and storing files a database will point to. If you already have access to a networked file system, consider that as an option, but don't add more work for yourself if you don't have to. Many applications I work on use the database to store pathnames while the files themselves are stored in a networked file system. It's honestly not a huge pain to manage this if it's already available, but as I mentioned before, there are caveats. Also, in my experiences, the amount of management you do in a database doesn't directly depending on the amount of data you put in. In other words, your database shouldn't become much more difficult to manage over time if all you are doing is adding more rows to tables. > I have read alot on this list and on other resources and there seems to be leanings toward 1+0 raids for storage. It seems to the most flexible when it comes to speed, redundancy and recovery time. I do want my database to be fully atomic. I think that is important as this database grows. Are my assumptions wrong? > As far as RAID levels go, RAID 10 is usually optimal for databases, so your assumptions are correct. The extra cost for disks, I believe, is paid off by the advantages you mentioned, at least for typical database-related workloads. RAID 0 doesn't allow for any disaster recovery, RAID 1 is ok as long as you can handle having only 2 disks available, and RAID 5 and RAID 6 are just huge pains and terribly slow for writes. Note that you should go for a battery-backup if you use hardware RAID. Hope this helps. Peter -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
