Create custom table for wordpress custom registration flow

I need to import some data about users from an application into the wordpress database. I’m thinking to use the wp_users and wp_users_meta tables to store these informations.

This is good, but directly interacting with the database will not flush caches, skips PHP hooks and actions, so you should expect either stale data, or compatibility issues with plugins.

Instead either use the REST API to do it via a HTTP request, or a WP CLI command to do it via CLI. This eliminates most of the work, avoids you writing SQL, handles all caches and plugins correctly, etc.

While I need to create accounts for each user that is in the table I also need to store additional details and the two tables seems perfect, but I’m not sure about this because the amount of entries will grow when new users will register to the site.

2000 users is miniscule, WP.com has hundreds of millions of users on a single multisite. The biggest problem there is calculating the pagination on the WP Admin users screen and the actual storage of all that data. At your rate of growth you should start encounter issues in the 22nd century assuming growth remains steady.

The biggest concern is user meta querys, if you’re going to be making lots of queries to find users who have a user meta with X or don’t have Y then the cost of extra users will no longer be linear.

What is the best approach for this situation, Do I need to create a custom table or I can rely without problems on the default tables of wordpress I’ve mentioned before?

Custom tables is the most difficult, most complex, most expensive, painful, and least compatible option. Expect lots of issues if you try to use custom tables for your users.

Just use standard WP tables, and use standard WP APIs to add the data.

E.g. https://developer.wordpress.org/cli/commands/user/create/

wp user create bob [email protected] --role=author

or

wp user meta add 123 bio "Mary is an WordPress developer."

Outputting a list of WP CLI commands to a script file then running that file on the host should be trivial. Afterall that’s how most SQL import/exports happen ( aka .sql files ).