How to connect to another database in Laravel (Multiple Database HUNDREDS)

Stefan Bogdanescu

Founder & Senior Architect · 2026-06-29

Laravel Company
# How to Connect to Multiple Databases in Laravel: Managing Hundreds of Connections Dynamically As a senior developer working with large-scale applications, managing multiple data sources is a common requirement. When you deal with hundreds of database instances, such as company branches, the challenge shifts from *connecting* to databases to *dynamically routing* requests to the correct one based on runtime context. Trying to manage hundreds of static connections directly within Laravel’s standard configuration files quickly becomes unmanageable and brittle. This post explores the most robust, scalable, and developer-friendly ways to handle dynamic database switching in a Laravel application, moving beyond simple `.env` manipulation toward true architectural solutions. ## The Pitfall of Static Configuration You asked how to manage hundreds of databases where each branch has its own schema or physical location. A tempting initial thought might be to iterate through `config/database.php` and dynamically swap the active connection. However, this approach is highly discouraged for several reasons: 1. **Configuration Bloat:** Manually listing hundreds of connections in a single file creates an unreadable configuration nightmare. 2. **Performance Overhead:** Establishing and maintaining hundreds of separate PDO connections simultaneously can strain your application server resources, especially under heavy load. 3. **Maintainability Nightmare:** Adding or removing branches requires constant modification of core Laravel files, increasing the risk of deployment errors. ## The Recommended Strategy: Dynamic Connection Resolution Instead of trying to force Laravel's default connection mechanism to manage hundreds of physical connections, the best practice is to use **dynamic routing**. You should define your database connections statically but implement a service layer that resolves *which* connection parameters are needed based on the user input (e.g., `branch_code`). This strategy separates configuration from execution, making your system scalable and much easier to maintain. ### Step 1: Statically Define Connections Keep your `config/database.php` clean. Define only the necessary connections, perhaps grouping them logically or using environment variables to pull connection details rather than listing every single branch explicitly in this file. For example, you might define a generic "branches" connection that points to a central data store, and then use separate logic to access the specific branch DBs. ### Step 2: Implement a Service Layer for Routing Create a dedicated service or repository class responsible for determining the correct database connection handle based on the input ID. This class acts as the intermediary between your application logic and the physical database connections. Here is a conceptual example of how this dynamic resolution might look: ```php // Example of a DatabaseResolver Service namespace App\Services; use Illuminate\Support\Facades\DB; class DatabaseResolver { /** * Determines the correct connection based on the branch code. * * @param string $branchCode * @return \Illuminate\Database\Connection * @throws \Exception If the database does not exist. */ public function getConnection(string $branchCode) { // In a real-world scenario, you would map this code to actual connection settings. $connectionName = 'branch_' . $branchCode; // Check if Laravel has registered this specific connection configuration. if (!config::has('database.connections.' . $connectionName)) { throw new \Exception("Database connection not found for branch code: " . $branchCode); } // Dynamically access the connection instance return DB::connection($connectionName); } } ``` ### Step 3: Using the Resolver in Your Controller/Logic Now, when a user requests data for a specific branch, your controller calls the resolver instead of directly calling `DB::table('some_table')` on a fixed connection. ```php // Example usage within a Controller method use App\Services\DatabaseResolver; class BranchController extends Controller { protected $resolver; public function __construct(DatabaseResolver $resolver) { $this->resolver = $resolver; } public function getBranchData(string $branchCode) { try { // Resolve the connection dynamically $connection = $this->resolver->getConnection($branchCode); // Execute the query on the selected branch database $results = $connection->table('branches')->get(); return response()->json($results); } catch (\Exception $e) { return response()->json(['error' => $e->getMessage()], 500); } } } ``` ## Conclusion: Scalability Through Abstraction Managing hundreds of databases in Laravel is not about trying to stuff them all into the `database.php` file; it’s about building an abstraction layer on top of them. By implementing a dedicated service layer, you achieve true separation of concerns. Your application logic remains clean and focused on business rules, while the service layer handles the complex, dynamic task of database routing. This approach ensures that your Laravel application remains highly scalable, maintainable, and adheres to the principles of clean code, making it an ideal pattern for large-scale enterprise applications. For more detail on structuring robust data access layers in Laravel, check out the best practices provided by [https://laravelcompany.com](https://laravelcompany.com).