Database vs. Schema vs. Database Server

[janpio]

On MySQL you have a database server with many databases. On PostgreSQL you have a database server with many databases with many schemas. In random SQL tooling database and schema are used interchangeably. Is there some "truth" behind all these names or did people just assign them randomly? What is correct, what is wrong, and is there a way to avoid confusion?

[imchairmanm]

I won't claim to know for sure, but as far as I've been able to tell, each of the database vendors kind of choose their own terminology. Schema is the most divergent one I think with PostgreSQL (and maybe Oracle?) using schema as a logical object within the database and holds some template-like information that databases can be spawned from. I'm not sure if we can take a hard stance on what you are "supposed" to use, but we can try to keep it clear for sure.

As far as I've been able to tell, in the most generic sense I think the most common way people use them is:

• Database: a specific database instance
• Schema: a design that defines the structure, constraints, etc.
• Database server: the thing that runs your database software or the database software itself

In terms of how we translate that, I try to tend to use the terminology of the specific DB I'm talking about but that gets tricky for more general conversations that apply to more than one project. Any suggestions on what you think would make sense?

[janpio]

I agree with how it is most commonly used database server -> database -> schema. Problem is that PostgreSQL uses "schema" as the "database", and has another layer which they do call "database". This leads to confusion with Prisma users (both internally and externally), and an article just spelling it all out would be helpful.

[imchairmanm]

Does this section do what you were looking for? I'm just trying to figure out if we already have something that would help us address this.

[janpio]

It does for PostgreSQL, yes.