Hey, I'm working in GIS field and I had the same problems. Solution I found, which has been working for the past year : virtual box on external drive ! This way you can have an independent OS (Linux for easy postgres/postgis/whatever gis you want).
I find it very comfortable because my server is separated from guest os. So I can take the disk and work on any pc with virtual box installed (require admin right), and I have all GIS tools on the server, so the virtual machine is very self contained. It is also easy to backup (but very slow due to huge iso file). I use a USB2 okay-ish disk. Guest win XP 64 / win seven 32 ; Host Ubuntu 12.04 32b. About perfo : I do complex queries. Perf are OK for my use case (about same as a dedicated XP 32bit). Using the external disk to hold a table space is a __very__ bad idea. As soon you do some upgrade/the disk get disconnected/anything happen, you are really screwed. (I had the issue. Without backup you can't do much without very strong postgres skills) Cheers, Rémi-C 2014-09-10 23:50 GMT+02:00 Steve Crawford <scrawf...@pinpointresearch.com>: > On 09/10/2014 02:00 PM, Daniel Begin wrote: > > First, I am a Newbie regarding PostgreSQL … > > > > I just started to look at PostgreSQL to implement a large GIS DB (1Tb). > The data must reside in an external disk with eSATA connection and may be > moved to different locations (and Windows desktops/laptops). I was looking > to install PostgreSQL and PostGIS extensions on each PC (setting-up the > proper PGDATA directory to the external disk) until I read about PostgreSQL > and PgAdmin Portable … > > > > http://sourceforge.net/projects/pgadminportable/ > > http://sourceforge.net/projects/postgresqlportable/ > > > > Is that a viable alternative considering the expected size of the DB? Any > comments or proposal would be appreciated J > > Daniel > > > It appears you are looking to take the PostgreSQL data directory from > machine to machine on an external drive. I fear you will run into some > potential problems: > > 1. Performance (mentioned by others). > > 2. OS mismatch. Have you ensured that all client machines are running > identical setups? The underlying files are not guaranteed portable between > OS versions and 64/32-bit. In fact they probably won't be. > > 3. Backups. What happens when one user screws up the database? > > Perhaps you could explain further the genesis of this requirement. The > message list is littered with questions like this asking how to implement a > certain solution when, given an understanding of the reason the question is > being asked, a far better solution exists. This happens even more often > when the person asking is a "newbie." > > Cheers, > Steve > >