What it means that vector indexes now live in the schema blueprint instead of a separate AI package — and how to migrate your embeddings table the right way.
A rollback migration for an embeddings table, written the way most teams have had to write it until now: DB::statement('DROP INDEX documents_embedding_index'), a raw SQL string sitting inside down(), hand-written because the schema builder had no concept of a vector index existing in the first place, let alone reversing one. It worked. It also meant the vector index was the one thing in that migration file that didn’t look like the rest of Laravel’s schema builder — everything else declarative and portable, one line raw and driver-specific, because the framework hadn’t caught up yet to a column type it had only recently started supporting at all.
That gap just closed. Blueprint::dropVectorIndex() landed in Laravel’s framework repository, delegating to grammar-level implementations for both MariaDB and PostgreSQL and reusing the same index-drop compilation path Laravel already uses for every other index type — named drops, column-based drops, the same two calling conventions developers already know from dropIndex(). This isn’t a flashy feature. It’s the unglamorous, necessary second half of a capability Laravel started shipping months earlier, and its arrival is the actual signal worth paying attention to: vector search just moved from “a thing you can bolt onto Laravel with the right column type and a lot of raw SQL” to “a first-class citizen of the schema builder, symmetric in both directions, the same way every other index has always been.”
Why a “Drop” Method Being Boring Is Exactly the Point
vectorIndex() — the creation side — shipped first, understandably, because creating something is always the part that gets built and demoed first. But a schema builder that can create an index and can’t cleanly drop it isn’t actually a complete abstraction — it’s half of one, with the other half quietly punted to DB::statement() and whatever raw SQL the specific database happens to need. That asymmetry is exactly the kind of gap that looks fine in a demo (nobody’s rolling back a migration in a demo) and becomes a real papercut the first time a team actually needs to reverse a schema change in a CI pipeline that runs migrations up and down as part of its test suite.
// Before dropVectorIndex() existed — the down() migration had to drop
// to raw SQL, breaking the pattern of everything else in the file
public function down(): void
{
Schema::table('documents', function (Blueprint $table) {
$table->dropColumn('embedding');
});
// This line doesn't look like anything else in a Laravel migration —
// driver-specific, hand-written, and easy to get subtly wrong across
// the two databases (MariaDB, Postgres) that actually support this
DB::statement('DROP INDEX documents_embedding_index'); // Postgres syntax;
// MariaDB's equivalent is different SQL entirely, so this single line
// was never actually portable across the two supported drivers anyway
}
// After dropVectorIndex() — symmetric, portable, looks like every
// other index operation in the schema builder
public function down(): void
{
Schema::table('documents', function (Blueprint $table) {
$table->dropVectorIndex('documents_embedding_index');
$table->dropColumn('embedding');
});
}
The real fix here isn’t just “one fewer raw SQL line.” It’s that the raw SQL line was never actually portable between MariaDB and Postgres in the first place — the DROP INDEX syntax genuinely differs between them — which meant a team supporting both had to maintain driver-conditional raw SQL by hand, in every migration that touched a vector column, forever. dropVectorIndex() pushes that driver difference down into the grammar layer, where Laravel has always kept exactly this kind of difference, instead of leaving it as homework in every individual migration file across a codebase.
Named Drops and Column-Based Drops — Matching the Convention Developers Already Know
The new method supports both calling conventions Laravel developers already use for dropIndex(), deliberately, so a vector index doesn’t require learning a second pattern just because it’s a different kind of index underneath.
// Drop by explicit index name — the same pattern as dropIndex('users_email_index')
Schema::table('documents', function (Blueprint $table) {
$table->dropVectorIndex('documents_embedding_index');
});
// Drop by column reference — Laravel resolves the actual index name
// the same way it does for a conventionally-named regular index
Schema::table('documents', function (Blueprint $table) {
$table->dropVectorIndex(['embedding']);
});
This symmetry matters more than it looks like it should, because it means a developer who already knows Laravel’s indexing conventions needs zero new mental model to reverse a vector index — the column-array-or-string-name pattern transfers directly, and the underlying implementation reuses the same index-drop compilation Laravel already had, rather than introducing a parallel, vector-specific code path that behaves subtly differently from everything else in the schema builder.
On an unsupported driver, this fails the way it should: loudly, at migration time, not silently or with a cryptic SQL error. The implementation includes an explicit unsupported-driver error — attempting dropVectorIndex() against, say, plain MySQL surfaces a clear, direct message that vector index dropping isn’t supported on that connection, rather than the migration either silently no-op’ing or throwing a raw database error that requires tracing back to “oh, this database doesn’t have this feature at all.” This is a small detail and it’s the right instinct: a capability gap between drivers should be a clear, immediate failure at the point it’s hit, not a mystery discovered downstream.
Migrating an Existing Embeddings Table the Right Way
For a team that’s already running a vector column in production, built before this landed — using raw DB::statement() calls for index management — the migration path is worth doing deliberately, not as a drive-by find-and-replace across the migration history.
// Step 1: a new migration that drops the OLD raw-SQL-managed index
// and recreates it through the new, portable schema builder method —
// don't retroactively edit old migration files that have already run
// in production; write a new migration that transitions forward
public function up(): void
{
// If the existing index was created via raw SQL, Schema::hasIndex
// (or an equivalent check) lets this migration run safely whether
// or not the index currently exists under the expected name
if (Schema::hasIndex('documents', 'documents_embedding_index')) {
DB::statement('DROP INDEX documents_embedding_index'); // one-time,
// to clear whatever raw-SQL-created index is currently there
}
Schema::table('documents', function (Blueprint $table) {
$table->vectorIndex('embedding', name: 'documents_embedding_index');
});
}
public function down(): void
{
Schema::table('documents', function (Blueprint $table) {
$table->dropVectorIndex('documents_embedding_index');
});
}
The reason this is worth a dedicated migration rather than silently continuing to use the old raw SQL going forward: every future migration touching this table — a column rename, an index rebuild, a rollback during a bad deploy — now goes through the same portable, grammar-aware path as the rest of the schema, instead of carrying forward a raw-SQL special case that has to be remembered and maintained by hand indefinitely. This is the same instinct as any technical-debt cleanup: the cost of migrating once, deliberately, is smaller than the compounding cost of every future migration needing to remember the old table is special.
Test the rollback, not just the forward migration, specifically because that’s the exact thing that was previously broken. A migration test that only runs up() and checks the schema afterward would have passed even in the old raw-SQL world — the actual gap this feature closes is down(), so a migration test suite that runs migrate then migrate:rollback and asserts the table returns to its prior state is what actually validates the fix did what it was meant to do.
it('can migrate up and roll back the embeddings index cleanly', function () {
Artisan::call('migrate', ['--path' => 'database/migrations/xxxx_transition_embedding_index.php']);
expect(Schema::hasIndex('documents', 'documents_embedding_index'))->toBeTrue();
Artisan::call('migrate:rollback', ['--path' => 'database/migrations/xxxx_transition_embedding_index.php']);
expect(Schema::hasIndex('documents', 'documents_embedding_index'))->toBeFalse();
});
The Actual Signal Underneath This Specific Change
A single new method on Blueprint is a small thing to build a whole argument around, and the argument isn’t really about this one method — it’s about what its existence implies for where vector search sits in Laravel’s own priorities. Features get their rough edges sanded down roughly in proportion to how core the maintainers consider them. A capability that’s expected to stay a niche, package-territory concern tends to stay half-finished — creation without a clean teardown path, a happy-path implementation with the edge cases left to whichever community package wants to paper over them. A capability the framework intends to genuinely own gets the boring, unglamorous second half built too: the drop method, the named-and-column-based calling convention parity, the explicit unsupported-driver error instead of a silent gap.
dropVectorIndex() shipping, built to the same symmetry standard as every other index type in the schema builder, is that second kind of signal. It’s a small PR that closes a real asymmetry, and the fact that closing it was worth doing at all — rather than leaving DB::statement() as the permanent, accepted answer for the teardown half of vector indexing — says more about where vector search sits in Laravel’s roadmap than any single splashy feature announcement would.
The One Rule
The unglamorous half of a feature — the rollback, the teardown, the reverse operation nobody demos — is usually the more honest signal of how seriously a framework is actually treating a capability, because it’s the half that only gets built once the maintainers expect people to actually depend on the feature in real, long-running production systems rather than just try it in a proof of concept. dropVectorIndex() existing, matching the exact calling conventions and failure behavior of every other index type Laravel has supported for years, is the framework treating vector search the way it treats a foreign key or a unique constraint — not as an experimental bolt-on, but as ordinary schema, expected to be created, migrated, and occasionally torn down and rebuilt, the same as anything else a real application’s database actually contains.