Data Model
Learn how NextKit defines the model of your SaaS application with Next.js and Supabase
NextKit's data model is voluntarily as simple as possible, with a limited set of assumptions.
NextKit is not supposed to be a finite product but a solid foundation on which it is quick to get started and build your SaaS product.
To summarize, the Postgres Database model contains the following tables: users
, organizations
, memberships
, subscriptions
and organizations_subscriptions
.
Users
Users are, of course, foundational to any application.
If a user signed in using Supabase Authentication, it merely means we have verified their credentials, not that they have an account.
We have to create an additional collection to store a user's data, such as:
- names (first name, last name)
- profile photo
- settings
- any other information which is not possible to update using their Authentication record (email, and login providers)
Below is the users
table:
Organizations
Organizations
are groups of users.
If the name doesn't suit your domain, don't worry: you can always change the terminology using the localization files.
Below is what the Organizations
schema looks like:
Memberships
To link an user to an organization we use another table named memberships
.
A user is associated to this table when:
- it is part of the organization
- it is not yet part, but has been invited
Furthermore, in this table we store the role
property which defines the role of the user for the organization.
Below is what the Organizations
schema looks like:
Invites
To create an invite to join an organization, we create a membership for the user with two properties code
and invite_email
: these two properties are going to become null
once the invite gets accepted.
User Roles
By default, NextKit defines three roles: Owner (can be only one), Admin, and Member.
This enum is hierarchical and associated with a number:
An Admin can do anything a member can do, and an Owner can do anything an Admin can.
Subscriptions
When users complete the Stripe checkout, the application will store some information from the subscription object sent by Stripe.
Below is the schema of the information stored in the Database:
To link a customer_id
from Stripe with an organization, we use a join table organizations_subscriptions
:
We store the customer_id
property so that, when an organization is first linked to a Stripe customer, can access their Stripe data using the Billing Portal.
When a subscription is active, the subscription_id
field will be populated with the subscription ID. Otherwise, the field will be null
.
Storage
By default, the kit also creates two Storage buckets: logos
and avatars
: