Introduction

In Laravel migrations, the cleanest way to make a timestamp column default to the current timestamp is usually useCurrent(). Laravel also supports raw SQL expressions, but the fluent schema helpers are clearer and more portable for the common case.

The normal Laravel way: useCurrent()

For a timestamp column that should default to the current database time when a row is inserted:

1use Illuminate\Database\Migrations\Migration;
2use Illuminate\Database\Schema\Blueprint;
3use Illuminate\Support\Facades\Schema;
4
5return new class extends Migration {
6    public function up(): void
7    {
8        Schema::create('posts', function (Blueprint $table) {
9            $table->id();
10            $table->string('title');
11            $table->timestamp('published_at')->useCurrent();
12        });
13    }
14
15    public function down(): void
16    {
17        Schema::dropIfExists('posts');
18    }
19};

This tells Laravel to generate a column whose default value is the current timestamp according to the database.

Older style: raw SQL expression

You may also see this pattern:

use Illuminate\Support\Facades\DB;

$table->timestamp('published_at')->default(DB::raw('CURRENT_TIMESTAMP'));

This works, but for standard "current timestamp" behavior, useCurrent() is usually easier to read and better expresses intent.

When the column should update automatically too

If you want the timestamp to update whenever the row changes, use useCurrentOnUpdate() in addition to or instead of useCurrent(), depending on the column's role.

$table->timestamp('updated_at')->useCurrent()->useCurrentOnUpdate();

This is commonly used for updated_at-style columns, not for immutable creation timestamps.

What about Laravel's built-in timestamps

If you use:

$table->timestamps();

Laravel creates created_at and updated_at columns. Whether they use database defaults or are managed by Eloquent depends on how your app writes data. In many Laravel applications, Eloquent sets those values itself rather than relying entirely on database-side defaults.

So if your goal is specifically "the database should provide the default current timestamp", define the column explicitly and configure it that way.

Database behavior still matters

Laravel migrations generate SQL, but the database is what ultimately enforces the default. MySQL, MariaDB, PostgreSQL, and SQLite do not behave identically for every timestamp-related feature.

For example:

• 'CURRENT_TIMESTAMP support is broad'
• auto-update behavior can vary by database engine
• timestamp precision may differ depending on column definition and database version

That is why it is smart to verify the generated schema in the actual database you deploy to.

A practical example for created and updated columns

If you want explicit control rather than relying on timestamps():

1Schema::table('posts', function (Blueprint $table) {
2    $table->timestamp('created_at')->useCurrent();
3    $table->timestamp('updated_at')->useCurrent()->useCurrentOnUpdate();
4});

This makes the database-level behavior obvious in the migration itself.

Database defaults are different from application-side assignment

If Eloquent sets the timestamp in PHP before insert, the database default may never actually be used for that row. That is not necessarily a bug, but it is worth deciding whether the authoritative default should come from Laravel code, the database schema, or both.

Common Pitfalls

• Using a raw SQL default when useCurrent() would express the intent more clearly.
• Expecting created_at to auto-update when only updated_at should do that.
• Assuming Laravel and the database handle timestamp defaults identically across all drivers.
• Mixing Eloquent-managed timestamps with database defaults without understanding which side is authoritative.
• Forgetting to verify the actual generated schema after running the migration.

Summary

• Use $table->timestamp('column')->useCurrent() for a current-timestamp default.
• Use useCurrentOnUpdate() when the column should change on updates too.
• 'DB::raw('CURRENT_TIMESTAMP') works, but is usually less clear than the fluent helpers.'
• Built-in Laravel timestamps and database defaults are related but not identical concerns.
• Always confirm how your target database handles the generated timestamp definition.