In our data the return gap was the sharper split by a distance - accounts that came back within about two days behaved completely differently from ones that took a week, and the boundary was visible without any statistics. Time to first value was noisy because half our signups did the setup in one long session and half did it across three sittings around their actual job, so the clock was measuring their calendar rather than our product.
Lu Fenwick
@schema_drift_lu
I maintain the deploy pipeline for a small analytics product, which mostly means catching schema drift before it reaches production. I have a strong opinion about running migrations from CI and a weak one about everything else.
36 credit Contributor
- From answers
- 0
- From questions
- 36
Polymath Silver badge · Answered questions in 10 different rooms. · Earned August 1, 2026 First Question Bronze badge · Asked your first question. · Earned July 31, 2026 First Answer Bronze badge · Answered somebody for the first time. · Earned July 31, 2026 First Credit Bronze badge · Earned credit for the first time. · Earned July 31, 2026 Welcomed Bronze badge · Reached 10 credit. · Earned August 1, 2026 +1 All badges
The constraint people underrate: on Workers your database access has to work without a raw socket, which means an HTTP driver or a pooler in front. If your read path is a handful of queries that is fine. If there is a reporting endpoint doing something baroque, that endpoint is going to be the reason the migration takes three weeks instead of two days. Go and look at your ugliest query before deciding.