Adding Multiple Postgres Databases to Hasura
Tags: database, multitenant
Published: 2021-03-29 10:18:58

---
title: Adding Multiple Postgres Databases to Hasura
published: true
date: 2021-03-19 14:53:10 UTC
tags: Database,MultiTenant
canonical_url: https://hasura.io/blog/supporting-multi-tenant-federated-data-graphs-with-hasura/
---

 ![Adding multiple Postgres databases to Hasura](https://hasura.io/blog/content/images/2021/03/multiple_postgres_blog.jpg)

Another new feature exclusive to the Hasura 2.0 release is support for multiple Postgres database types. In just a few clicks you can add an an extra database, existing or new, track the tables, enable relations, and unlock the power of GraphQL.

## Supporting multi-tenant, federated data graphs with Hasura

The reason multiple database support is so helpful is that it enables two powerful goals in modern app development, namely, multi-tenant architecture and federated graphs, also called unified graphs.

### Multi-tenant architecture

Multi-tenant architecture, or multi-tenancy, is the ability to have isolated data structures maintained in a unified ops platform. Different application types often require different data structures, or new initiatives often inherit legacy database structures that are expensive or difficult to migrate, and maintaining out-of-date practices would lead to slower development of the new features/initiatives. To maintain these disparate systems leads to managing login/authentication in multiple systems, log management in different platforms, and, quite often, billing complexity spread across a wide array of cloud providers.

### Unified dev-ops

With Hasura you can add your existing databases so that you have observability, tracking, maintenance, and migrations in a single console. You no longer need to pay the high cost of context switching or negotiate the dance of browsers sessions. With a singular backend, you also have a common method for accessing data which leads to an increase in developer efficiency.

### Data model optimization with polygot workloads

Modern applications are a hodgepodge of different data structures. Some data needs to be wide-table, some data needs to be highly descriptive, others need to be ultra lean. Some data needs to be optimized for tight access controls, others for high-read. These data models are often custom tailored for transactions, time-series eventual consistency, or for multiple indexes for multi-dimensional analytics. Switching between single-purpose providers for each of these services can lead to significant cognitive, financial, staffing, and security overhead. Supporting and unifying all these services with a single back-end again yields substantial operational improvements.

### Creating federated graphs

The last large benefit we see arise as a bi-product of this feature is support for federated (unified) graphs out of the box. As applications increase in sophistication and embrace wildly varying workloads, being able to communicate across data sets without sacrificing on performance or security allows teams to surface insights that otherwise lay behind layers of complicated infrastructure or sitting at the bottom of a data lake.

Multiple Postgres support will substantially change the way teams build modern applications and we can't wait to have you try it out. Learn more in the video below.

{% youtube ozd6PjOpGy8 %}