Hi everyone,
I’ve been running Manticore in production for about two years, mostly from a Laravel API. I ended up building something I haven’t seen in the ecosystem yet and wanted to share it here.
Since Manticore speaks the MySQL wire protocol, I registered it as a native Laravel database connection — a custom connection + a thin query/schema grammar. The result is that the entire Eloquent ORM works on Manticore directly: models, query builder, pagination, casts, and even migrations that create RT tables.
Article::where('published', true)
->match('laravel', '(title,body)')
->option('ranker', 'proximity_bm25')
->paginate();
Migrations map Laravel column types to Manticore types, plus Manticore-specific ones:
Schema::connection('manticore')->create('articles_rt', function (Blueprint $table) {
$table->text('body');
$table->mva('tag_ids');
$table->floatVector('embedding', dims: 384); // KNN
$table->minInfixLen(2);
$table->morphology('stem_en');
});
KNN, FACET, OPTION, HIGHLIGHT and REPLACE are exposed as builder methods. Things that don’t map to MySQL semantics are handled explicitly — e.g. update() only touches attribute columns, and full-document rewrites go through an explicit replace(); transactions/locks are documented as unsupported.
Repo (MIT, 95% test coverage, Laravel 10/11/12):
It’s running in production on my side, but I’d really appreciate eyes from people who know Manticore internals better than I do — especially:
- Edge cases in SQL dialect differences I might have missed in the grammar (builder combinations that compile to SQL manticore rejects);
- Whether forcing PDO emulated prepares is still the right call for the MySQL endpoint, or if there’s a better approach for bound MATCH() parameters.
Happy to answer anything, and feedback/issues are very welcome.