Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Tomasz_Kisiel's avatar

One API for many databases.

Hey. I have an application to which I sell access to a group of customers - paid subscription. Each buyer receives his subdomain and database with many tables. Each buyer provides the key to his subdomain to his employees so that they can register and log in.

Each such subdomain is now a separate Laravel instance. Due to the fact that I have more and more clients, maintaining coherence between instances becomes difficult. In addition, I want to extend the application with a mobile application that needs a good api.

I am creating an API that should be able to handle multiple databases simultaneously. Each base is constructed the same way. So I would like one model or controller to be able to handle data from different databases.

The API requires authorization and this is where my problem comes from. Because I have users in different databases, I don't know how to check if the given email and password are correct.

When logging in, the application on the user's side sends an email, password and unit, which means which database to use. But how can I tell the Auth class which database to use?

My current LoginController@login looks like this:

function login() {

	// In request()->input('unit') i have database name
	// Before Auth::attempt i want to say laravel to use specific db.. how to tell it him ?

	if( Auth::attempt(['email' => request()->input('email'), 'password' => request()->input('password')]) ) {
		$user = Auth::user();
		$user->generateToken();

		return response()->json(
			$user->api_token
		, 200);
	}

	return response()->json([
		"error" => "Unauthenticated."
	], 401);
}

PS. I don't use Passport or JWT - only my code

PS2. Of course all databases are included in config/database.php

0 likes
15 replies
bugsysha's avatar

Each buyer receives his subdomain and database with many tables. Each such subdomain is now a separate Laravel instance.

If these two statements (sentences) are correct then all your headache should be solved by changing values in .env file for appropriate database name and credentials?

Tomasz_Kisiel's avatar

Not quite ... indeed, so far each subdomain is a separate instance .. but in my question I want to have one instance, e.g. api.my-app.com and on unit1.my-app.com only have fronted ( React), which sends queries to api. To get the answer he must authenticate and get a token. I just don't know how to do this with many databases. For example, I have 10 databases and 10 users tables, and different users in each .. I am now trying with JWT and guards

bugsysha's avatar

Just add all client users to one database which is used for auth and then based on that user fetch the remaining data.

Why does everyone create multiple databases/tables for these kinds of apps I do not get it?

NicolasMica's avatar

👋 Hi there !

I'm assuming each request will have that unit input right ?

It sounds like you could use a middleware to check the unit input to switch to the correct database connection for the current request.

Tomasz_Kisiel's avatar

Maybe I can agree with you that in current situation is stupid. But have you beeter idea? One database is the simplest solution.

But in each database I have a lot of data intended only for users of this database. So how can I combine all the databases into one and not lose this functionality?

I also think that separate databases are more secure, isn't it?

Tomasz_Kisiel's avatar

Yep. Each request have information about unit. I tried with middleware but it didn't work out as intended. I used the command

Config::set('database.connections.mysql.database', $unit)

..but it didn't seem to work because laravel was constantly throwing that [mysql] is undefined.

I am generally ready for big changes. If there is a better option to prepare applications for many tenants, each of whom has access to their data, please let me know.

Tomasz_Kisiel's avatar

Maybe I should have one db any separate tables for all tenancy like: db.app_unit1_users db.app_unit2_users And then make authentication not for many db but for many tables.. it seems to be simpler, but it's look ugly for my..

bugsysha's avatar

No tenancy overhead. Unless you are obligated by law or contract that you have to give database dump to your clients at their request there is no advamtage for it. One database. Generic table names without any prefixes or suffixes.

1 like
Tomasz_Kisiel's avatar

Fortunately, unfortunately I have in contracts that I am the only administrator (actually this is my one-man company), he knows if something goes wrong I have to take all responsibility, but I have the right to devote everything (almost everything: P).

Generally, no one cares what happens on the server side, as long as there is no data leakage.

I will try to add a unit field to each table and decide what to display to whom by this field. What do you think?

londoh's avatar
londoh
Best Answer
Level 5

@tomasz_ek there are many valid reasons for needing to split multi tenant data out into separate DB's.

I've used that tenancy package, and I've found it excellent. It covers much more than switching db's, altho there is a learning curve.

It's def worth checking out, before you decide whether it's worth the rewrite at this stage or not.

1 like
Tomasz_Kisiel's avatar

Personally I prefer have all tanent in separate db with one API for all, but I also still looking for the best solution..

Tomasz_Kisiel's avatar

Do you know any good guide to this package? Because in addition to documentation, I wish to see a good example to understand it.

Please or to participate in this conversation.