Modern applications often perform multiple database operations as part of a single business process.

For example, when a customer places an order, your Laravel application may need to:

• Create an order
• Create order items
• Update product inventory
• Record a payment
• Update the order status

What happens if the first three operations succeed but the payment record fails?

Without proper transaction handling, your database can be left with partial and inconsistent data.

This is where Laravel database transactions and error handling become essential.

In this guide, you’ll learn how to use Laravel transactions with DB::transaction(), beginTransaction(), commit(), rollBack(), exception handling, deadlock retries, and best practices for building reliable Laravel applications.

---

What Is a Database Transaction in Laravel?

A database transaction groups multiple database operations into one logical unit.

The main principle is simple:

Either all database operations succeed, or none of them are permanently saved.

Suppose an application transfers ₹5,000 from one account to another.

The process involves:

Account A → Deduct ₹5,000
Account B → Add ₹5,000
Transaction History → Create Record

All three operations should succeed together.

If the money is deducted from Account A but the application fails before updating Account B, the data becomes inconsistent.

A database transaction helps prevent this.

All Operations Successful
        ↓
      COMMIT
        ↓
Changes Saved Permanently

If an error occurs:

An Error Occurs
      ↓
   ROLLBACK
      ↓
Changes Reverted

---

Why Use Laravel Database Transactions?

Laravel transactions are useful whenever multiple database operations depend on each other.

Common use cases include:

• E-commerce order processing
• Payment transactions
• Bank transfers
• Wallet systems
• Inventory management
• Booking systems
• User registration
• Multi-table database updates

Transactions help maintain:

• Data consistency
• Data integrity
• Reliable error recovery
• Atomic database operations

---

Using DB::transaction() in Laravel

The simplest way to create a transaction in Laravel is with DB::transaction().

use Illuminate\Support\Facades\DB;

DB::transaction(function () {

    // Database operations

});

Laravel automatically handles the transaction lifecycle.

If everything succeeds

Laravel commits the transaction automatically.

If an exception is thrown

Laravel automatically rolls back the transaction.

This makes DB::transaction() the preferred approach for many common use cases.

---

Simple Laravel Transaction Example

Let’s create a user and a related profile.

use App\Models\User;
use Illuminate\Support\Facades\DB;

DB::transaction(function () {

    $user = User::create([
        'name' => 'John Doe',
        'email' => 'john@example.com',
        'password' => bcrypt('password'),
    ]);

    $user->profile()->create([
        'bio' => 'Laravel Developer',
    ]);
});

Both operations are treated as one transaction.

If the user and profile are created successfully, Laravel commits the transaction.

But if profile creation throws an exception, Laravel rolls back the transaction, so the user record is not left behind as incomplete data.

---

How Laravel Transactions Handle Errors

Consider this example:

DB::transaction(function () {

    Order::create([
        'user_id' => auth()->id(),
        'status' => 'pending',
    ]);

    throw new Exception('Something went wrong.');
});

Because an exception is thrown, Laravel automatically rolls back the transaction.

The order will not be permanently saved.

This is one of the biggest advantages of DB::transaction().

Important: For Laravel to automatically roll back the transaction, the failure must propagate as an exception.

---

Laravel Transaction with Try-Catch

You can combine DB::transaction() with try-catch to handle errors and return a useful response.

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

try {

    DB::transaction(function () {

        // Database operations

    });

    return response()->json([
        'message' => 'Operation completed successfully.',
    ]);

} catch (\Throwable $e) {

    Log::error('Transaction failed', [
        'message' => $e->getMessage(),
    ]);

    return response()->json([
        'message' => 'Something went wrong.',
    ], 500);
}

In this approach:

1. Laravel starts the transaction.
2. Your database operations run.
3. Laravel commits automatically if successful.
4. Laravel rolls back if an exception occurs.
5. The outer catch block handles the error.

This keeps transaction management and application error handling cleanly separated.

---

Real-World Example: Creating an Order

Let’s look at a practical e-commerce example.

When a customer places an order, the application needs to:

1. Create the order
2. Create order items
3. Check available stock
4. Reduce product stock

All of these operations should succeed together.

use App\Models\Order;
use App\Models\OrderItem;
use App\Models\Product;
use Illuminate\Support\Facades\DB;

try {

    DB::transaction(function () use ($cartItems) {

        $order = Order::create([
            'user_id' => auth()->id(),
            'status' => 'pending',
            'total' => 2500,
        ]);

        foreach ($cartItems as $item) {

            $product = Product::findOrFail(
                $item['product_id']
            );

            if ($product->stock < $item['quantity']) {
                throw new Exception(
                    'Insufficient product stock.'
                );
            }

            OrderItem::create([
                'order_id' => $order->id,
                'product_id' => $product->id,
                'quantity' => $item['quantity'],
                'price' => $product->price,
            ]);

            $product->decrement(
                'stock',
                $item['quantity']
            );
        }
    });

} catch (\Throwable $e) {

    return back()->withErrors([
        'error' => $e->getMessage(),
    ]);
}

If one product has insufficient stock, an exception is thrown.

Laravel rolls back everything that happened inside the transaction.

That means:

Order Created          → Rolled Back
Order Items Created    → Rolled Back
Stock Updated          → Rolled Back

The database remains consistent.

---

Manual Transactions in Laravel

Sometimes you need more control over the transaction.

Laravel allows you to manually manage the transaction lifecycle using:

• DB::beginTransaction()
• DB::commit()
• DB::rollBack()

The standard structure looks like this:

use Illuminate\Support\Facades\DB;

DB::beginTransaction();

try {

    // Database operations

    DB::commit();

} catch (\Throwable $e) {

    DB::rollBack();

    throw $e;
}

---

Understanding beginTransaction(), commit(), and rollBack()

DB::beginTransaction()

This starts a new database transaction.

DB::beginTransaction();

Changes made after this point are part of the active transaction until it is committed or rolled back.

---

DB::commit()

This permanently saves the changes.

DB::commit();

Only call commit() after all required database operations have completed successfully.

---

DB::rollBack()

This cancels changes made during the transaction.

DB::rollBack();

It should usually be called when an exception or failure occurs.

---

Manual Transaction Example with Error Handling

Here is a complete example:

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

DB::beginTransaction();

try {

    $order = Order::create([
        'user_id' => auth()->id(),
        'status' => 'pending',
    ]);

    Payment::create([
        'order_id' => $order->id,
        'amount' => 1500,
        'status' => 'completed',
    ]);

    DB::commit();

    return response()->json([
        'message' => 'Order created successfully.',
        'order' => $order,
    ]);

} catch (\Throwable $e) {

    DB::rollBack();

    Log::error('Order transaction failed', [
        'message' => $e->getMessage(),
    ]);

    return response()->json([
        'message' => 'Order could not be created.',
    ], 500);
}

The transaction flow is:

BEGIN TRANSACTION
        ↓
Create Order
        ↓
Create Payment
        ↓
Everything Successful?
      ↙       ↘
    YES        NO
     ↓          ↓
  COMMIT    ROLLBACK

---

DB::transaction() vs Manual Transactions

Both approaches are useful.

Feature	DB::transaction()	Manual Transaction
Easy to use	Yes	Moderate
Automatic commit	Yes	No
Automatic rollback on exception	Yes	No
Custom transaction flow	Limited	More control
Recommended for common use cases	Yes	When needed

Recommended approach

For most situations, use:

DB::transaction(function () {

    // Database operations

});

Use manual transactions when your application genuinely needs explicit control over when the transaction starts, commits, or rolls back.

---

Error Handling Best Practices in Laravel Transactions

1. Always Handle Unexpected Exceptions

Database operations can fail for many reasons:

• Invalid data
• Database connection problems
• Foreign key constraints
• Deadlocks
• Duplicate records
• Unexpected application errors

Wrap important transaction workflows with appropriate error handling.

try {

    DB::transaction(function () {
        // Database operations
    });

} catch (\Throwable $e) {

    report($e);

    // Handle the failure
}

---

2. Do Not Swallow Exceptions

This is a common mistake:

DB::transaction(function () {

    try {

        // Database operations

    } catch (\Exception $e) {

        // Error ignored
    }
});

If you catch the exception and do nothing, the transaction callback may finish successfully.

Laravel may then commit the transaction.

Instead, rethrow the exception if the transaction should fail:

DB::transaction(function () {

    try {

        // Database operations

    } catch (\Throwable $e) {

        throw $e;
    }
});

This allows Laravel to detect the failure and roll back the transaction.

---

3. Keep Transactions Short

Do not keep a database transaction open longer than necessary.

Avoid slow operations inside a transaction, such as:

• Calling external APIs
• Sending emails
• Uploading files
• Long-running calculations

For example, avoid:

DB::transaction(function () {

    Order::create([
        // Order data
    ]);

    // Slow external API call
    $paymentGateway->process();
});

External services can be slow and may hold database locks longer than necessary.

Keep the transaction focused on related database operations whenever possible.

---

Use afterCommit() for Post-Transaction Actions

Some actions should only happen after the database transaction has successfully committed.

For example:

• Sending notifications
• Dispatching certain jobs
• Triggering follow-up processes

You do not want to send a success notification if the transaction later fails and rolls back.

Conceptually, the correct flow is:

Database Transaction
        ↓
      COMMIT
        ↓
Send Notification

This helps ensure that follow-up actions are based on data that was successfully committed.

---

Laravel Transactions and Queue Jobs

Be careful when dispatching jobs inside a transaction.

Imagine this flow:

Start Transaction
      ↓
Create Order
      ↓
Dispatch Job
      ↓
Transaction Fails
      ↓
Rollback

The job could potentially run while the database changes are not yet committed or after they have been rolled back, depending on the configuration and timing.

For transaction-dependent jobs, consider dispatching them only after the transaction has successfully completed.

The same principle applies to events and notifications that depend on committed database data.

---

Handling Database Deadlocks

In high-traffic applications, multiple transactions can sometimes conflict with each other.

For example:

Transaction A locks Record 1
Transaction B locks Record 2

Transaction A needs Record 2
Transaction B needs Record 1

This can create a deadlock.

Laravel allows you to specify retry attempts with DB::transaction():

DB::transaction(function () {

    // Database operations

}, 5);

In this example, Laravel can retry the transaction when a deadlock occurs, up to the configured number of attempts.

Deadlock retries can be useful in applications with concurrent operations, such as:

• E-commerce platforms
• Inventory systems
• Wallet applications
• High-traffic APIs

---

Transaction Example with Inventory Protection

Consider two users trying to purchase the last available product at almost the same time.

A basic stock update might create race conditions.

A safer approach is to perform the critical database operations together.

DB::transaction(function () use ($productId) {

    $product = Product::where('id', $productId)
        ->lockForUpdate()
        ->firstOrFail();

    if ($product->stock <= 0) {
        throw new Exception(
            'Product is out of stock.'
        );
    }

    $product->decrement('stock');
});

lockForUpdate() can help protect critical rows during the transaction, depending on your database and transaction isolation behavior.

This is especially useful when multiple requests may update the same data concurrently.

---

Logging Transaction Errors

Logging errors helps you investigate production problems.

use Illuminate\Support\Facades\Log;

try {

    DB::transaction(function () {

        // Database operations

    });

} catch (\Throwable $e) {

    Log::error('Database transaction failed', [
        'message' => $e->getMessage(),
        'user_id' => auth()->id(),
    ]);

    throw $e;
}

Avoid logging sensitive information such as:

• Passwords
• Authentication tokens
• Credit card information
• Secret API keys

Log enough information to debug the problem without exposing sensitive data.

---

Common Laravel Transaction Mistakes

Forgetting to Call rollBack()

With manual transactions, always ensure that failures trigger a rollback.

catch (\Throwable $e) {

    DB::rollBack();

    throw $e;
}

Using DB::transaction() can reduce the risk of forgetting this.

---

Committing Too Early

Do not commit the transaction before all related database operations are complete.

Bad flow:

Create Order
   ↓
COMMIT
   ↓
Create Payment → Failed

The order is already permanently saved.

Instead:

Create Order
   ↓
Create Payment
   ↓
Everything Successful?
   ↓
COMMIT

---

Catching an Error Without Re-Throwing It

If a failure should cancel the transaction, do not silently ignore it.

Make sure the exception propagates or explicitly roll back the transaction.

---

Performing Too Much Work Inside a Transaction

Long transactions can increase database locks and reduce application performance.

Keep the transaction focused and short.

---

Laravel Database Transaction Best Practices

Follow these best practices:

1. Use transactions for related database operations.
2. Prefer DB::transaction() for simple workflows.
3. Use try-catch around critical business operations.
4. Always roll back manual transactions on failure.
5. Keep transactions as short as possible.
6. Validate request data before starting the transaction.
7. Do not silently ignore exceptions.
8. Log important transaction failures safely.
9. Avoid unnecessary API calls inside transactions.
10. Trigger dependent actions only after a successful commit.
11. Consider deadlock retries for high-concurrency operations.
12. Use row locking carefully for critical concurrent updates.

---

Frequently Asked Questions

What is DB::transaction() in Laravel?

DB::transaction() executes database operations inside a transaction. If the callback completes successfully, Laravel commits the transaction. If an exception is thrown, Laravel rolls back the changes.

Does Laravel automatically roll back transactions?

Yes, when using DB::transaction(), Laravel rolls back the transaction when an exception escapes the transaction callback.

What is the difference between commit and rollback?

commit() permanently saves the changes made during a transaction, while rollBack() reverses the uncommitted changes.

Should I use try-catch with DB::transaction()?

Yes, an outer try-catch is useful when you want to log the error, return a custom response, or perform other application-level error handling.

Can I use Eloquent models inside a Laravel transaction?

Yes. Methods such as create(), save(), update(), and delete() can be used inside Laravel database transactions.

When should I use a database transaction?

Use a transaction when multiple database operations must succeed or fail together to maintain data consistency.

---

Conclusion

Laravel database transactions and error handling are essential for building reliable applications.

Whenever several database operations are part of one business process, you should think about what happens if one operation fails halfway through.

Laravel gives you two main approaches:

DB::transaction(function () {

    // Laravel handles commit and rollback

});

Or manual control:

DB::beginTransaction();

try {

    // Database operations

    DB::commit();

} catch (\Throwable $e) {

    DB::rollBack();

    throw $e;
}

For most applications, DB::transaction() provides a clean and reliable solution.

The key principle to remember is:

When related database operations must succeed together, wrap them in a transaction and handle failures properly.

By combining transactions, exception handling, safe logging, deadlock awareness, and short transaction scopes, you can protect your Laravel application from partial updates and keep your database consistent.