Hello! New to supabase here. Is there an explanation somewhere on what the default schemas are for? I see there is public, which I assume is where my tables for things like users will go, but what are the other schemas for like auth, extensions, graphql_public, etc.

Hello @Masn! This thread has been automatically created from your message in #843999948717555735 a ``few seconds ago``. Pinging @User so that they see this as well! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ... menu) and select Leave Thread to unsubscribe from future updates. Want to change the title? Use the

/title

command! We have solved your problem? Click the button below to archive it.

Correct -

public

is where you'd put your tables, most functions you create, etc. This works for most use cases. Consider this schema a playground for your project until you get to the point that you're ready to build it into an actual project.

auth

is where the details of your registered users are stored (amongst other things which are all related to authentication). You generally shouldn't mess with anything in here unless you're intending to e.g. delete a user from the DB entirely.

extensions

is where extension functions and such are stored. This can include things like the

crypt

function, and if you enable an extension like PostGIS, this schema is where the functions for that are installed. In general, you wouldn't ever want to mess with this schema.

realtime

is where details of realtime updates are stored. I don't have a whole lot more information on this as I've not used realtime for quite some time. Someone else might have more info on this though.

Masn (2022-03-28)

Thank you for the info! So for the most part, I will only be dealing in public. Question about my users table. I will still have a separate users table in the public schema correct? @User

You don't need to have a separate users table in public, but I think most people do so because it makes it easier to manage custom information (the other option is putting it onto the metadata of a user in the auth schema, but that's just JSON so managing it can be tricky due to lack of defined structure)

Ok great, thank you very much