Multi-tenancy application using Database-per-tenant model.

• A new database is provisioned for each new tenant.
• The application tier is scaled up vertically by adding more resources per node.
• Or the app is scaled out horizontally by adding more nodes.
• The scaling is based on workload, and is independent of the number or scale of the individual databases.

The use of single-tenant databases gives strong tenant isolation. In any app whose model specifies only single-tenant databases, the schema for any one given database can be customized and optimized for its tenant. This customization does not affect other tenants in the app. Perhaps a tenant might need data beyond the basic data fields that all tenants need. Further, the extra data field might need an index.

With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve.

In such a case, a design to carefully manage schema customizations at scale should be taken into consideration.

1. Auth
   • Handles authentication
2. Profile
   • Handles user profile
3. Other Services:
   • Groups : Manage groups which have multiple policies attached to.
   • Policies: Entities with permissions attached to which are attached to groups.
   • Permissions : Granular entities that control access to the tenant.

• To update as more items are added

• Gin
• PostgreSQL
• Redis
• Docker
• Kubernetes
• SQLC
• Golang Migrate

• Replace Auth service implementation with an identity provider (Auth0 or Cognito)
• Expose both REST and gRPC endpoints using gRPC gateway.
• Re-do the project using Microservice Architecture.
• Attempt Sharded Multi-tenant approach.

Multi-tenant SaaS database tenancy patterns

MIT Licence