What else would you want on a typical pivot table...say for posts and tags.

migration.php

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class PivotPostTagTable extends Migration {

    /**
	 * Run the migrations.
	 *
	 * @return void
	 */
	public function up()
	{
		Schema::create('post_tag', function(Blueprint $table) {
			$table->integer('post_id')->unsigned()->index();
			$table->integer('tag_id')->unsigned()->index();
			$table->foreign('post_id')->references('id')->on('post')->onDelete('cascade');
			$table->foreign('tag_id')->references('id')->on('tag')->onDelete('cascade');
		});
	}



	/**
	 * Reverse the migrations.
	 *
	 * @return void
	 */
	public function down()
	{
		Schema::drop('post_tag');
	}

}

1. An id auto increment will give better performance on high load.
2. Indexes on all the fields. (Fixed)

+1 Yeah, the recomendation is have an id on all your table, even the pivot tables, and what about the timestamps ?

#2 is fixed. Just forgot to add that.

I wasn't sure what the rule was on adding an auto-increment id to joinables. But I can add it easily if that's a good rule to follow.

Okay, so now, when you run:

php artisan generate:pivot tags posts

...it'll generate the following migration:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class PivotPostTagTable extends Migration {

    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('post_tag', function(Blueprint $table) {
            $table->increments('id');
            $table->integer('post_id')->unsigned()->index();
            $table->integer('tag_id')->unsigned()->index();
            $table->foreign('post_id')->references('id')->on('post')->onDelete('cascade');
            $table->foreign('tag_id')->references('id')->on('tag')->onDelete('cascade');
        });
    }



    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('post_tag');
    }

}

@montogeek timestamps it's more an user preference I think. I usually add it. I suggested @JeffreyWay that it could be an option.

That's is because I suggested it, I use to add it too, will be great has option! :)

I think I'm going to leave timestamps off for the time being. Takes two seconds to add it manually.

I know you said you were going to leave it off, but just for reference, I +1 the addition of timestamps

Could you make the foreign key constraints optional (default on is fine).