Shared vs Dedicated Database Servers

Dedicated Database Server

By default, a CollectionSpace server stores data for one or more museums or collections ("tenants") intermingled in a single nuxeo database.

If more than one tenant is present - and by default, sample core and lifesci tenants are present, as well as any tenants you might yourself create - the data (rows in database tables) belonging to any one tenant can be distinguished from data belonging to other tenants only via database queries which include JOINs, in part based on tenant IDs.

This default behavior can compel more effort to isolate the data belonging just to a single museum or collection, for backups or other purposes. (In practice, however, most or all CollectionSpace installations to date have featured just a single tenant, plus the two sample tenants - which are typically unused in that scenario - so only data relevant to that single tenant is present in the database, making this concern more theoretical than practical.)

Still, there may be scenarios in which you may yet want to store your museum or collection's data in its own database, perhaps one named after your institution. If so, you can make this configuration change at the time you set up a new tenant for your museum. See the relevant instructions in Creating your new tenant how to do this via configuration.

The link above should take you directly to the relevant instructions within the "Creating your new tenant" document. If not, you may need to scroll down just a small distance in the instructions to find it.

Advantages of Sharing a Database Server

Sharing a database server between multiple CollectionSpace systems 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.

Setting up a Shared Environment

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

To avoid complications, it is highly recommended that you perform both of these configuration changes during initial installation of your CollectionSpace systems. Be sure to make these changes immediately after the installation step where you download the CollectionSpace source code, before you proceed any further with installing CollectionSpace.

• Specifying that each of these systems will connect to the same shared, remote database server. For details, see Remote PostgreSQL Database Server.

• Giving each of them their own instance identifiers: simple names which uniquely identify each CollectionSpace instance. For details, see Naming 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.