I can see what you mean, but most startups try to have users as early as possible, to demonstrate traction. Most also practice continuous deployment. In the early stage, a lot of refactoring usually happens, which often requires database migrations. If we are afraid to refactor our database because our service may be unavailable and disappoint our early adopters, then we lose velocity and peace of mind. A tool like PostgreSQL solves this, with a small admin overhead compared to SQLite.

And the admin overhead can be reduced by using a managed service (Amazon RDS, Google Cloud SQL, Digital Ocean Managed Databases, etc.). With a managed service, we can even go serverless for the rest of the app. With SQLite, we have to closely manage and backup our server since the data are stored on it.

> I'm not sure I agree that the delay of the blocking write from a migration is so long as to cause significant (if any) damage to the business.

I agree that most migrations, in the early stage of a project, run for a few seconds to a few minutes maximum. But in my experience that's usually enough to be noticeable by our users.

> If SQLite makes development and deployment easier (I think it does)

I agree. That's why I use it sometimes :)

On the same topic, about the “server-process-edition” branch of SQLite: https://news.ycombinator.com/item?id=17766799