Laravel 13.27 introduces a per-connection setting that masks query bindings out of exception messages, preventing sensitive data like emails from leaking into logs and APM spans. It adds a whereBinary() family for byte-exact, case-sensitive comparisons on MySQL and MariaDB, plus refreshForUpdate() to reload an Eloquent model under a pessimistic lock without re-querying by primary key. Other additions include a Cloud facade for Laravel Cloud checks, queue total-size methods across all queues, MariaDB support for vector distance queries, Postgres keepalive DSN options, shared AWS credential caching for SQS, and several input-handling and validation-hardening fixes.
Table of contents
# Masking Query Bindings in Exception Messages# whereBinary() for Case-Sensitive Comparisons# refreshForUpdate()# A Cloud Facade# Queue Totals Across Every Queue# Vector Distance Queries on MariaDB# Input Handling and Validation Hardening# Other Fixes and ImprovementsQuestions this post answers
How do I stop Laravel from putting bound query values into exception messages?
Laravel 13.27 adds a per-connection config key called mask_bindings_in_exception_messages that keeps ? placeholders in QueryException messages instead of interpolating the actual values. Set it via DB_MASK_BINDINGS=true, since the key already ships in the framework's default config/database.php. It defaults to false, and only the exception message text changes; getBindings() still returns real values. daily.dev surfaces framework release details like this for teams hardening logging and error handling in Laravel.
How do I do a case-sensitive WHERE query in Laravel with MySQL?
Laravel 13.27 adds whereBinary(), orWhereBinary(), whereNotBinary(), and orWhereNotBinary() to the query builder for byte-exact comparisons on MySQL and MariaDB, replacing the need for whereRaw('name = BINARY ?'). Postgres, SQLite, and SQL Server throw a RuntimeException since those already compare case sensitively by default. Developers picking the right case-sensitivity approach per database engine can track Laravel query builder changes on daily.dev.
How do I take a pessimistic lock on an Eloquent model I already loaded before a transaction started?
Laravel 13.27 introduces refreshForUpdate(), which behaves like refresh() but applies lockForUpdate() to the reload query, refreshing the existing model instance in place rather than requiring a fresh findOrFail() query by primary key. It must be called inside a transaction, since the lock only holds for the transaction's lifetime, and it closes the read-then-write data race on that model. daily.dev helps developers dealing with concurrency and locking bugs in Laravel keep up with fixes like this.