SRM 6.1.1 and embedded PostgreSQL database

[jftwp]

Is anyone who is using the embedded database experiencing any issues?  I've read the install/config guide and apparently the embedded db is just as scalable as using an external SQL db where maximums, etc are concerned.  Other than that, the guide (and release notes) mention no caveats and provide backup/restore procedures via cmd line which is fine (and which I will do).  Just being cautious before implementing, because we've experienced some vendor's variants of PostgreSQL db's wherein the 'vacuuming' can become problematic or other issues have arisen.  I just don't want to kick myself in the future for not having used an external SQL database instead, as I've done for prior versions of SRM going back nearly 10 years, but using the embedded makes the overall deployment infinitely easier.  Trade off?

For what it's worth, I can't FIND anything/anyone complaining about the Postgre database in either SRM 5.8 or 6.1.x

Thanks for any feedback.

[vbrowncoat]

I haven't heard of any issues/complaints. Using the embedded DB makes for a much simpler experience, potentially lower licensing costs and all the same performance and scale. For all of the installs I do internally I always use embedded.

[jftwp]

Thanks.  One thing I noticed about the backup process noted in the install guide is that you don't necessarily have to stop the SRM service itself.  I was able to generate a backup file via running the script shown in the guide, so I think I'll just schedule a weekly command to run backups.  I'm also backing up the entire SRM server itself as part of a regular rotation, via VADP/Commvault.

Anyone else have comments/experience using the embedded database?  I'll give it a week before marking gs_khalsa comment as 'Correct'.