Laravel - change the default database connection globally
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Laravel: Mastering Dynamic Database Connection Switching Globally
As a senior developer working with Laravel, managing multiple database connections is a common requirement, especially in applications that support multi-tenancy or complex data routing. The goal is often to allow users to switch context dynamically—for instance, switching between `db1` and `db2` based on a selection in a dropdown menu or a URL parameter.
This post dives into the nuances of how Laravel handles configuration changes at runtime, specifically focusing on setting the default database connection globally, and addresses why simple use of `Config::set()` might not immediately provide the persistent behavior you expect across page refreshes.
## Understanding Laravel Configuration Loading
When your Laravel application boots up, it loads all configuration files from the `config` directory, including `database.php`. The initial default connection is established based on how Laravel initializes its services. While you can modify configuration settings at runtime using methods like `Config::set()`, these changes are primarily applied *within the scope of the current request*.
Your observation that setting the value in a test method worked momentarily confirms this: when you call `$users = User::all()` immediately after setting the default, Laravel uses that newly set value for that single operation. However, as soon as the request ends and a new one begins (like a page refresh), the application reloads the configuration from its persistent storage (the files or database), effectively resetting your dynamic change.
## The Illusion of Global State vs. Request Scope
The core misunderstanding often lies between modifying configuration *for the current request* and setting a true *global state*. Laravel, by design, manages requests in an isolated manner. If you need a setting to persist across multiple user interactions or page loads, it must be stored somewhere external to the immediate request cycle.
If you are using this feature for session-based user preferences, the correct place to store the selected database is within the **Session** or in a **Database Table**. Relying solely on `Config::set()` is like writing a temporary note on a whiteboard that gets erased when the room is cleared.
## Implementing Persistent Dynamic Switching
To achieve the desired global switch—where selecting an option results in the correct database being used on subsequent requests—we need to store the chosen state persistently.
Here is a practical approach using the session to maintain the selected connection until the user explicitly makes another choice:
### Step 1: Storing the State (The Controller Logic)
Instead of setting the configuration directly, we store the preference in the session. This ensures that when the next request comes in, we retrieve the preference from the session instead of relying on a transient configuration change.
```php
use Illuminate\Support\Facades\Config;
use Illuminate\Http\Request;
public function postChangeDb(Request $request)
{
$selectedDb = $request->input('db');
// Store the chosen database in the session for persistence
session()->put('current_database', $selectedDb);
// Optional: You can now load the configuration based on this stored value
Config::set('database.default', $selectedDb);
return response()->json(['message' => 'Database switched to ' . $selectedDb]);
}
```
### Step 2: Retrieving and Applying the State (The Middleware or Service Layer)
In your application, any part of the code that needs to interact with the database must first check the session before attempting to read the configuration. This ensures consistency regardless of how the request was initiated.
When you are working on complex data management within Laravel, understanding these state management patterns is crucial for building robust applications. For deeper dives into application architecture and best practices, I highly recommend exploring resources from [Laravel Company](https://laravelcompany.com).
## Conclusion: Persistence Through State Management
The short answer to your question is: **No, the switch using `Config::set()` is not inherently persistent across requests.** It affects only the current request's configuration context.
To change the default database globally and persistently, you must externalize that state storage. By coupling your dynamic selection mechanism with Laravel's Session or a dedicated database table, you create a reliable mechanism for tracking user preferences. This approach ensures that your application maintains data integrity and predictable behavior, which is fundamental when developing scalable systems on the Laravel framework.