GlobalDB is a DB intended to hold more than one partitions. This can happen in cases that there is not a good enough reason for the partitions to have their own database. This lets the user save money on a new dedicated machine, while still enables them to enjoy the benefits of a distributed system.

GlobalDB is especially useful for multi tenants DBs / SaaS database architecture, since there is no necessity to configure new tenants at the Gate.

If a tenant (A single partition in our platform) is undefined it will simply be routed to the GlobalDB by the Gate,

It is still always preferred to create a partition at the Gate; however, we can still accommodate this situation using GlobalDB.

Another reason that makes the GlobalDB useful is the fact that in the event of an organization that is unprepared to receive a new partition entity (a new branch of a bank for example, or a new car dealership, a new department of an organization, etc.) the DBA has to do nothing more than to create another partition at the gate and the gate itself will do the rest. If the Gate processes a command which holds a PartitionId that is different from those who are already configured, it will automatically infer that the DB responsible for that transaction is the GlobalDB and will route the command accordingly,

So, no one can ever catch you off-guard.

Everything we said about a partition, applies to GlobalDB. It derives its table structure, stored procedures, functions, triggers, synonyms, and the like, from the Gate just like any other ChildDB – the only difference between the two is that a globalDB holds multiple partitions.

Another aspect that is identical to a GlobalDB and a ChildDB (partition) is the working in front of a CommonDB (to learn more about a CommonDB click here)

To learn more how ChildrenDB (and GlobalDB included) work with the CommonDB click here.