I wonder how an alternate timeline might have played out if Richard Hipp had not named it "SQLite" and instead called it "SQLightning" or "SQLExpress" or something like that. For much of its lifetime, SQLite wasn't taken seriously despite being an extraordinary technology and part of me is convinced it was in large part due to "Lite" being in the name.

I don't think it has much to do with the name. I think the biggest perceptual impact on SQLite came from Rails, and its default for using SQLite as a test database while strongly discouraging people from using it in production.

To be fair, serving any kind of traffic with Rails required multiple replicas of Rails application running. So SQLite wasn't an option for production for any kind of production rails workload.

Then most hosting for rails were stateless, so you had no way of storing SQLite on disk.

And finally, for serious production you need high availability and SQLite couldn't offer that.

Would Go's concurrency be an issue for SQLite too?

Edit: I looked into a common Go driver for SQLite[1] and the FAQ reads,

> Can I use this in multiple routines concurrently?

> Yes for readonly. But not for writable. See #50, #51, #209, #274.

Every time I see a blog post from fly.io reg SQLite I'm tempted to use it for my next project, But the need to rewrite my framework for limited data types and the doubts regarding concurrency keeps me away.

[1] https://github.com/mattn/go-sqlite3