[tptacek]

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.

[post-it]

Django too.

> By default, the configuration uses SQLite. If you’re new to databases, or you’re just interested in trying Django, this is the easiest choice. SQLite is included in Python, so you won’t need to install anything else to support your database. When starting your first real project, however, you may want to use a more scalable database like PostgreSQL, to avoid database-switching headaches down the road. [0]

[0] https://docs.djangoproject.com/en/4.1/intro/tutorial02/

[tptacek]

Sure, Django too.

[0x457]

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.

[Abishek_Muthian]

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

[tptacek]

My general M.O. for SQLite in Go is to have a single writer thread with a channel of closures to apply transactions, and a shared db handle for reads. Works fine.

[Abishek_Muthian]

That's an useful information, Thanks for sharing.

[randomdata]

I think it's older than that, even predating SQLite. Back when Perl/CGI was all the rage it was common to store data in files. But the web was growing fast and scaling files was hard. Pushing that workload onto the heavyweight RDMBS was seen as the solution, reasonably so in some cases, but that also brought the cargo culting along with it.

When SQLite arrived it got lumped in with file storage that can't scale. Rails only perpetuated what everyone was already thinking.

[nigma]

There are many reasons for using other databases like PostgreSQL or MySQL in production - feature set, (managed) hosting, backup and replication, etc.

SQLite is primarily embedded/local database and cannot be easily separated and shared over network [1] between multiple disposable backend/worker instances.

[1] https://12factor.net/backing-services

[tptacek]

Yes, that's what Rails (and Django) say about it.

[deepstack]

yeah when it comes to embbed, if one is willing to go the java road, then H2 is an excellent DB to use. It is some what Postgres compliant.