OrbisDB is built on top of multiple components, mainly PostgreSQL, Ceramic and the OrbisDB Node itself. You can learn more about roles of each in our Architecture overview (link).
How and if you’re going to run each of these depends on the environment you’re using OrbisDB in, as well as your hosting requirements.
OrbisDB comes with two modes built-in: dedicated and shared.
Shared OrbisDB instances allow multiple separate environments on a single OrbisDB instance - similar to a shared (multi-tenant) hosting environment.
Each environment is logically isolated, including separate databases, owners and limited configuration options. All environments share the same underlying hardware, network and Ceramic node.
A Shared OrbisDB instance has one administrator. They handle the core configuration such as Database and Ceramic connections.
An example of a Shared OrbisDB instance is OrbisDB Studio (link), hosting multiple environments for users to get started with OrbisDB.
Dedicated OrbisDB instances are meant to serve a single client (an app or a project).
This means a single database, environment, owner (administrator) and configuration.
Dedicated instances are easier to scale, as the load is predictable and depends on a single consumer.
Most currently running OrbisDB instances are dedicated.
| Shared | Dedicated | |
|---|---|---|
| Environments | 1 per consumer | 1 |
| Users | 1 per environment | 1 |
| Administrators | 1 | 1 |
| Scalability | 🟡 | ✅ |
| Databases | 1 per environment | 1 |
As is the case with other web services, OrbisDB can be hosted locally, in the cloud or via a managed hosting provider. This is true for each separate component, as they don’t have to be hosted on a single server.
Docker images are provided for a quicker setup.