How I’m Developing a Multi-Tenant SaaS Application Using Next.js and PostgreSQL

Tenant slug is created in the first segment of the path. Next.js retrieves the slug and then finds the right restaurant using the slug.

The development process of path-based tenancy is easier as there is no need for wildcard domain names or DNS configurations.

Subdomain-based tenancy

With subdomains, each restaurant receives an address like:

fifth-avenue.example.com
fifth-avenue.domain.com

Sounds good, particularly if one wants to achieve better brand image in the restaurant. However, beneath the hood subdomains require additional efforts: wildcard DNS, domain management, middleware deployment, and other issues which I do not have to solve from day one.

So for the first version, I am going with path-based tenancy:

domain.com/fifth-avenue

This may be less glamorous, but it provides exactly what I require at this time – an easy method for brand recognition, testing of the product on real tenants, and getting the tenant isolation done before dealing with any additional infrastructure.

Preferred Architecture for a beginner

The architecture begins when someone visits a restaurant URL like:

some-domain.com/fifth-avenue

For an example URL like example.com/fifth-avenue, the application considers fifth-avenue as the unique tenant slug of the restaurant in question. Next.js reads the slug from the dynamic route and sends it to the server, where the application searches for the tenant associated with the restaurant in the PostgreSQL database.

Provided that the restaurant is valid and active, the database returns the tenant’s record, which contains the ID, name, branding, and configuration of the restaurant in question. This ID becomes the reference ID used for the rest of the process to get categories and menu items associated with the Fifth Avenue restaurant and render the restaurant’s public menu.

The process above is vital since the URL cannot determine the data to load on its own. The application has to confirm the slug provided by reading it from the database first before proceeding. For an example URL like example.com/unknown-restaurant, the application has to display the appropriate not-found message.

Multi-tenant isolation of tenant data in PostgreSQL

Here are a few ways that multi-tenant databases can be arranged:

1. Database per tenant
2. PostgreSQL Schema per tenant
3. Shared tables with tenant ID

For my initial restaurant SaaS, I will be using shared databases and shared tables. One tenants table will hold restaurant data. Restaurant-owned data tables will have a tenant_id column. Some of the entities are likely to be:

1. tenants
2. users
3. tenant_members
4. categories
5. menu_items
6. restaurant_settings

For instance, two restaurants might have a menu item named “Zinger Burger” belonging to different tenants.

Whenever the application requests Classy Café’s menu, the query must filter Using the tenant ID of Classy Café. This approach is more straightforward and cost-effective compared to keeping a database of each small restaurant separately. However, it does need some effort because all tenant-owned queries should have an appropriate tenant restriction.Without an appropriate tenant condition, one can disclose data from other restaurants, which makes tenant isolation a security measure.

Uncertainties I faced during planning

My initial confusion was on whether I had to use a different database for every restaurant. This will be much more isolated physically, but it will unnecessarily complicate operations at the beginning. The other confusion was on whether I should start off with sub-domains or dynamic paths. Sub-domains seem more sophisticated, but they don’t actually solve the issue of tenant isolation. The queries have to remain secure anyway. The most crucial lesson learned from the planning phase is that multi-tenancy isn’t about manipulating the URL in any way. It is about passing the proper context of the tenant through all operations of authentication, authorization, and databases.

The Road Ahead

A multi-tenant SaaS solution is not just about one app showing restaurant names. It should know which restaurant the request is about and secure its data all the way through. For version one, I have selected an architecture that is realistic: Next.js dynamic routing and one PostgreSQL database with tenant IDs for restaurant records. It will make the system easy to manage as I test out the core functionality. Once the system is stable, I will add more complex features like subdomains, custom domains, subscriptions, analytics and ordering. The project documentation will go on as I shift from architectural design to database design and implementation.