Supabase Scalability: Choosing the Right Database Architecture
Hello everyone!
I hope you’re all doing well. I have a question related to our architecture and scalability. Refining our systems, we explore the best approach for handling our database instances about scalability. Specifically, we’re considering whether to have multiple database instances or rely on a single one that can scale with the Supabase plan sizes (XL, XXL, etc.).
Our Key Considerations:
1. Scalability: How well can our architecture grow as our user base expands? Are there any real-world examples of how different plans handle user loads?
2. Multiple Instances vs. Single Scalable Instance: Should we build our architecture to accommodate multiple database instances, or is it sufficient to rely on a single instance that can scale vertically?
Additional Concerns:
1. Supabase Auth Integration: We currently use Supabase Auth for user authentication. If we opt for multiple database instances, we must address how authentication would work across these instances. The authentication layer must be above the Supabase database instance, ensuring consistent user access regardless of the underlying database.
2. Routing and Storage: Routing user authentication and managing session data become critical in a multi-database structure. How do we efficiently route authentication requests to the appropriate database instance?
Our Current Approach:
We’re in the estimation phase, evaluating our options and gathering insights. Currently, we have separate database instances for each client, which has served us well. However, as we transition to a multi-tenant database model focusing on building a scalable model that can handle a significantly larger user base, we must plan strategically.
Your Insights:
If you have experience with similar scenarios or can share best practices related to Supabase Auth and multi-database architectures, we’d greatly appreciate your input.
Best regards,
Aron
I hope you’re all doing well. I have a question related to our architecture and scalability. Refining our systems, we explore the best approach for handling our database instances about scalability. Specifically, we’re considering whether to have multiple database instances or rely on a single one that can scale with the Supabase plan sizes (XL, XXL, etc.).
Our Key Considerations:
1. Scalability: How well can our architecture grow as our user base expands? Are there any real-world examples of how different plans handle user loads?
2. Multiple Instances vs. Single Scalable Instance: Should we build our architecture to accommodate multiple database instances, or is it sufficient to rely on a single instance that can scale vertically?
Additional Concerns:
1. Supabase Auth Integration: We currently use Supabase Auth for user authentication. If we opt for multiple database instances, we must address how authentication would work across these instances. The authentication layer must be above the Supabase database instance, ensuring consistent user access regardless of the underlying database.
2. Routing and Storage: Routing user authentication and managing session data become critical in a multi-database structure. How do we efficiently route authentication requests to the appropriate database instance?
Our Current Approach:
We’re in the estimation phase, evaluating our options and gathering insights. Currently, we have separate database instances for each client, which has served us well. However, as we transition to a multi-tenant database model focusing on building a scalable model that can handle a significantly larger user base, we must plan strategically.
Your Insights:
If you have experience with similar scenarios or can share best practices related to Supabase Auth and multi-database architectures, we’d greatly appreciate your input.
Best regards,
Aron
