How to correctly create a database of users?

Question

Database design

The task is to develop a web service. Music theme.
It will be a website, a mobile app and a smart TV app. More precisely, this is such an interface for requests to the server.
The question is, when registering, there is a choice of "listener" or "executor". Each of these groups will have both general functionality (such as search, add to playlist .. .. ) and personal, for example, the listener cannot upload music, video clips to the service.
So. Would it be correct to create two tables in the users database: the Listeners table and the Performers table.? Or write all users into one table (I think this is less productive)
And the second. Is it possible to do so. For example, divide users into tables with id. for example id from 0 to 100000, with id 100001 to another table. And when logging in or searching for a user, speed up the search. For example, if id > 100000, but less than 200000, look in table 1. Otherwise, in table 2. Such is the idea. Please describe your thoughts. Will it reduce the load on the server? Will it speed up the service.
So far, I am collecting the best solutions and ideas in advance, but to be honest, I don’t know from which side to approach the project.
Of course, at this stage it is easier to draw a design, but I don’t understand how to start writing a server .. with such functionality ..
Or at least - to give birth to some kind of MVP project.

Answer 1

How many total users are planned? Up to a million it doesn't matter at all - one table, and then look at the load. And I think that the problem will not be with user tables at all, believe me. These are the most unloaded tables and queries, if you approach authorization and authentication correctly, for example, on tickets.

Answer 2

What happens when the performer also wants to become a listener? Does he need to create a new account? (some services create such crap, not allowing you to combine roles)
Life is such that as soon as you have people in your database, then create a separate table structure for people, regardless of their roles, and already add roles and properties to it with links, associated with them.
Therefore, you should have a peoples table and links to it musicians and listeners
Advice, try to avoid situations when you need to pack something in identifiers, some information, in bits like yours. This imposes a bunch of restrictions later on optimization (for example, sharding across several servers) or limits the number, because you can’t guess the limits in advance. Do not skimp on the fields, there is information you need to use - add a field or even an entire table
Another piece of advice, don't define user functionality restrictions through the structure... today you think of restricting listeners from uploading music, tomorrow you want to allow it, but if you initially put into the structure that this is not the case, modification can become expensive. Also, today you think that you have only two roles, tomorrow you will come up with three, in a year the investor will want five more, and programmers will, instead of adding more fields and tables to the structure, rewrite the entire database completely.