DDEV

Worth it when file speed is what hurts.

What it does better

Its file sync is dramatically faster than a bind mount on macOS — measured in tens of milliseconds where a mount takes seconds. On a project where composer install or a watch process is the daily cost, that is the difference that matters.

It also brings a large community and its own ecosystem of add-ons, and it issues its own trusted certificates on start.

What it costs

Starting and stopping is slow, and worse the bigger the project. Four projects open at once: 141.7 s against docker's 16.8 s to bring them up, and 28.6 s against 9.6 s to take them down. The largest of them — seven sites, Elasticsearch and a queue worker — is 63.1 s against 2.9 s on its own. That is where the gap stops being a number and becomes a morning. On a project with several sites that gap is felt every morning, because one registration is one directory — so a project serving four sites is four DDEV projects to bring up, one after another.

That is the trade to weigh. DDEV wins a page render (66 ms against docker's 104), and loses the day's starts and stops by a much larger factor. Which matters more depends on whether your time goes into requests or into switching between projects.

One registration is one directory with one URL. ddev list shows a multi-site project as unrelated entries. dqx registers each site's directory so the project still works as one, but the model underneath does not change — and it is why dqx list exists in the shape it does.

The sync can go out of step, and larger projects are where it happens. It is documented and recoverable, and dqx has a repair path for it, but a bind mount cannot go out of sync at all. On a project with a large node_modules this is a real risk rather than a theoretical one, and it is also where the slow starts come from: a huge directory in the sync set has been measured taking minutes. Excluding it (upload_dirs) is the fix, and it is worth doing before the first slow morning rather than after.

It uses more memory — 9.6 GB against docker's 4.4 GB for the same four projects, of which Mutagen alone is 1.1 GB — and it writes its own config. dqx generates it, so the declaration stays the source, but .ddev/ belongs to DDEV's schema rather than dqx's.

Switching

dqx switch ddev

dqx refuses rather than trying when the project needs something this backend cannot give — several sites from one checkout, for instance. The refusal names what it is.