Sharing a database server between multiple CollectionSpace systems

In a hosted configuration where you are managing multiple CollectionSpace systems, you may want to have two or more of those systems share a single database server. CollectionSpace has supported this capability beginning with /wiki/spaces/collectionspace/pages/666274109 (and specifically, with the minor bugfix Release 4.1.1).

Doing so offers a variety of advantages; among these:

• Fewer database servers to manage, overall.
• Allowing your CollectionSpace system instances to be run on lightweight, relatively inexpensive hosts, such as small virtual machines or containers. (These savings, in turn, could be used to reduce hosting costs, or else to improve performance by providing more memory, and more and faster disk space, to the database servers.)
• The option to host dedicated database servers, which can often be:
  
  • Managed by experienced database administrators.
  • Configured for optimized database performance, particularly when not having to take into account other software running on the same machine.

To do so, configure two or more of your CollectionSpace systems with the following options:

• Specifying that each of these systems will connect to the same shared, remote database server. For details, see Configuring CollectionSpace to connect to a remote PostgreSQL database server.
• Giving each of them their own instance identifiers: simple names which uniquely identify each CollectionSpace instance. For details, see Configuring a CollectionSpace system with an instance identifier. (Doing so helps keep the database objects associated with each CollectionSpace system separate, and thus avoids "name collisions.")

And, as well:

• Ensure that the shared, remote PostgreSQL database server is configured to allow a sufficient number of total simultaneous connections, to accommodate such shared use.