v24
Enhanced AI Capabilities with Vector Support & Optimized Caching Performance We are thrilled to announce ...
Learn more
A modern system can be built in many different ways. This is part of the beauty, and the curse, of working in software development and architecture. Factors that influence decisions in system design can be a mixture of cost, ease-of-use, familiarity, or anything in between. There is no blueprint for building the perfect system, but there are some tools that can make it much easier. One of such tools is multi-tenanted systems. At Dgraph, we have made multi-tenancy a staple of our product. It has allowed teams to move faster, with less effort, and with unrivaled flexibility. Multi-tenancy may not always make sense to use, but when you need it, it’s great to know that Dgraph can support that need with minimal effort. Let’s dive a little further into what multi-tenancy is and exactly why your organization may want to use it!
Multi-tenanted systems are nothing new. As computers and software became more commonplace, we had to develop ways to leverage the hardware we had for multiple users. The earliest example of this would be the era of time sharing in the 1960s. Multiple companies would use a single mainframe and divide up their usage. This meant that companies could use a single server to serve the needs of the many groups that needed it.
Fast forward to today, you’ll now see that multi-tenanted systems are everywhere. Not to be confused with virtualization, multi-tenancy is when users share the same application, running on the same operating system, on the same hardware, with the same data storage. Using a multi-tenant approach allows users to use the same solution but within its own silo so that there is some segregation.
A common scenario is when a company buys a system and multiple groups within that organization want to use it. They could all use the same system, a single-tenanted approach, with the risk of trampling over each other’s work or data. They could also create a separate physical instance for each group to use to solve this problem. This approach would likely come with a substantial increase in cost and maintenance.
These solutions may work in some scenarios but may not be as advantageous for others. A multi-tenant approach would allow each group to have its own logical “instance” where only their group or team’s work is done. Other teams would also get the same type of division. Each group is isolated from and invisible to one another, ensuring privacy and security. The system itself would feel, to the users, as though they have their own instance. In reality, multiple groups are using the same resources but are logically separate.
If that is still not quite clear, let’s put it into a different frame. Looking at Dgraph as a single-tenant system versus a multi-tenant system is quite easy. As a single-tenant, we can think of it as a house, with all of the plumbing, electrical, and other services that make the house run. Each of these components are only used by the people living in that house. In a multi-tenant, we can think of it as an apartment building where all of these services are shared. Tenants in each apartment can use the electric, plumbing, and other services as they would if they had their own house. The difference is that they are actually sharing all of these resources amongst all the other tenants of the apartment building, even though they are in control of their own space.
In a nutshell, multi-tenancy allows for a single instance to serve multiple groups as though each group has its own instance.
Now that we know what it is, why would we want to use multi-tenancy? There are many reasons why multi-tenancy may make sense and a few scenarios where it could be applied. Here are a few that come to the top of my mind.
Since infrastructure is shared across multiple tenants, there is no need to have multiple servers and licenses to run new instances of Dgraph. The need to only have a single instance of Dgraph to serve multiple groups of users can drastically reduce the costs associated with running Dgraph. This is in comparison to having an individual and physically separate instance for each group, which requires more server resources, time to set up and manage, and licenses to run.
When running a multi-tenanted system, you need to set up and configure the system only one time. Once it is up and running, tenants and users can easily be added with minimal effort. If there is an issue within the system, it can be fixed and applied in a single place. This is also true with upgrades, where instead of updating each instance you can just update a single instance and that will cascade out to all tenants on the system. With individual instances, these tasks become difficult to manage and track. This is yet another benefit to leveraging multi-tenancy.
If a group or user requires a new instance of Dgraph, a single-tenanted approach requires new servers, configuration and installations, and licenses. This obviously takes time, resources, and overall means that onboarding is going to take longer. This may delay the start of development since provisioning a new system can cause such inconveniences. With multi-tenancy, administrators can easily create a new namespace and give users instant access to their own “logical” instance. Users can be up and running in a matter of minutes and organizations can benefit from the advantages mentioned above.
Of course, every organization may have different reasons for pursuing a multi-tenanted system outside of these three suggestions. With multi-tenant solutions supplying such a robust experience with so many benefits, it’s no wonder they have become so popular and desired.
The last step is to begin to use multi-tenancy in Dgraph. In Dgraph Cloud, configuring a multi-tenanted environment has never been easier. It’s important to note that multi-tenancy is an enterprise feature. It can be enabled when you are using a Dedicated instance on Dgraph Enterprise.
With Dgraph, our approach to multi-tenancy revolves around the idea of namespaces. Each namespace is essentially a tenant. The namespace allows for schemas, data, and other functionality within Dgraph to be logically separated.
Namespaces can be created and assigned to different users. Those users would then only have access to their “instance” or namespace. This allows us to use a single Dgraph instance to serve the purposes of many different groups. To the users of each tenant or namespace, the underlying multi-tenancy would not be observable.
Once multi-tenancy is enabled, an administrator would create a namespace and assign users access to that namespace. The users added can then log into that namespace, or tenant, and use Dgraph to begin development. It’s truly that simple.
To get started today, sign up for a Dedicated Dgraph instance on Dgraph Cloud. Multi-tenancy is just a few clicks away!
Until next time, stay tuned for upcoming blogs and tutorials on multi-tenancy in Dgraph to help get you up and running quickly!
