I read Paul Redmond's write-up of the new DB::olap() method on Laravel News this morning, and my first reaction was a mix of "nice, small, useful" and "I want to be suspicious of this before I trust it". I haven't run it against a PlanetScale branch yet. So everything below is a read of the article, the pull request and PlanetScale's docs, plus some opinions about where I'd get burned. Not a benchmark.

Short version for the impatient: DB::olap() is a tidy way to lift PlanetScale's per-query row cap for one callback. It is good for occasional exports and backfills. It is a bad default for anything a user is waiting on, and it has one trap that code review will miss.

What the limit actually is

PlanetScale runs MySQL on Vitess, and by default every query runs in an OLTP workload with guard rails. According to the PlanetScale system limits page , a query there can return, update or delete at most 100,000 rows, and a result set tops out at 64 MiB.…