Multi-tenant App

📊 Low-Code Apps
#1

Hi I’m new to Corteza and I’m trying to evaluate on how to design a multi-tenant application in Corteza. What are the multi-tenancy options supported?
I’m also trying to understand how to model the data store such that it can support pooled multi-tenancy.

Hoping for the needed guidance from the community and thank you in advance.

Thanks,
Calvin

#2

Hi @Ccbeloy

no proper multi-tenancy support yet, we will start working on high availability as it is one of the main features we want to tackle in the near future.

What is your use-case?

You can simulate multi-tenancy by having separate namespaces for each client and handling access with RBAC.

Or on a different level, you can host different corteza instances inside k8s on different pods.

#3

A multi-tenant application is a software architecture where a single instance of the software serves multiple customers or “tenants.” This model is common in cloud computing and Software as a Service (SaaS) solutions, where it allows multiple customers, businesses, or organizations to use the same application infrastructure and features while maintaining data isolation and operational efficiency.

Choosing Between Single-Tenant and Multi-Tenant

The choice between single-tenant and multi-tenant architectures often depends on several factors:

  • Security Needs: Organizations with stringent security and compliance requirements may prefer single-tenant solutions.
  • Budget Constraints: Smaller organizations or those with less critical security requirements might opt for multi-tenant solutions due to cost efficiency.
  • Scalability Requirements: Companies that need to quickly scale might prefer the flexibility offered by multi-tenant environments.
  • Customization Requirements: Enterprises needing significant customization may benefit from single-tenant setups.

In summary, each architecture has its pros and cons, and the decision to choose one over the other should align with the organization’s specific needs, strategic goals, and customer requirements.

Modeling a data store effectively requires careful planning and consideration of the data’s nature, the operations that will be performed on the data, and the performance requirements of your application. Here are the general steps and considerations to take when modeling a data store:

Choose the Right Data Store
SQL vs. NoSQL: Decide whether a relational (SQL) or non-relational (NoSQL) database suits your needs based on the data types, relationships, and the queries you expect to run.

Relational Database (SQL): Use if your data is structured and consistent relationships exist between entities (e.g., MySQL, PostgreSQL).

Non-Relational Database (NoSQL): Use for unstructured data, flexible schemas, or when scaling and performance are priorities (e.g., MongoDB, Cassandra, Redis).

Specialized Data Stores: Consider using specialized data stores like time-series databases, graph databases, or full-text search engines based on specific requirements.

Model the Data
For Relational Databases:
Normalization: Organize the data in your database into tables and columns, avoiding redundancy and dependency by normalizing the data up to a suitable normal form to reduce duplication and improve data integrity.

Define Relationships: Clearly define primary keys, foreign keys, and the relationships between tables (one-to-one, one-to-many, many-to-many).
Indexes: Implement indexes on columns that will be frequently searched against, which helps in speeding up query times.

For NoSQL Databases:
Document Stores (e.g., MongoDB): Group data logically within documents. Design your schema based on query patterns and ensure that most frequent query patterns are efficient.

Key-Value Stores (e.g., Redis): Decide on the key format and structure. Typically, simple query patterns are best suited for key-value stores.

Wide-Column Stores (e.g., Cassandra): Model around your query patterns, optimizing for reads by clustering data that is queried together.

Graph Databases (e.g., Neo4j): Model your data as nodes, edges, and properties if your data naturally forms a graph and you need to efficiently query relationships.

1 Like