Just seems strange that is actually a problem.
Don't get me wrong, I use SQLite ... it's just not the database for my company's management web portal.
I see the sqlite hype as a (legitimate) pendulum swing away from defaulting to 'web scale' everything to a realization that most of the systems we design don't need it.
On the other hand, when you start mixing in new tech like litefs to paper over shortcomings in the fundamental nature of an alternative, I start to question the sanity of the choice.
We have screwdrivers, hammers, wrenches, let's not select a wrench and wrap it in a 'screwdriver adapter as a service'.
My hats off to you on this comment, even more so if you are the originator. Personal experience shows that I have added more complexity by spinning up a postgres server 'in case I need it' more often than not.
That was exactly my thought, the majority of work that gets put out there isn't going to need to scale to many different nodes to serve thousands+ of concurrent users. If you're actually serving tonnes of traffic and need clustering or high end redundancy, have at 'er. But for most of the professional work I've done, SQLite is more than enough (provided you back it up properly!)
I think this is also influenced by my philosophy of keep things simple and only scale when you need to. I haven't had need of k8s or anything like that and suspect many companies serving small-medium traffic loads don't either.
And I also use SQLite in places I definitely shouldn't be.
You may be noticing it more out of a frequency bias (baader-meinhoff effect) situation.
Generally, you can just run the `postgres` command, but it creates many unnecessary hurdles:
* Just want to invoke `postgres`? Not possible, you need to invoke `initdb` first. Why can't `postges` do that for automatically you if the DB dir doesn't exist, like other servers do (e.g. `consul`)?
* Depending on your invocation, you're likely to run into errors mentioning "initdb: invalid locale settings; check LANG and LC_* environment variables". Why isn't there a simple UTF-8 default?
* Postgres refuses to run as `root`; that's unoverridably hardcoded in its code. So you can't "just start it" when you're `root` inside a container or VM in which only postgres runs. It can't run well under `unshare` when you want things to shut down reliably on cancellation in CI. This constraint should just be removed; no other software refuses to run as root. This mindset is indeed from 27 years ago.
* You can't start an in-memory postgres for quick testing or CI. This feature does not exist.
All of this is fixable, but it currently creats the "oh you can 'just run' postgres, but not in random conditions A, B, C and D".
Also an in memory Postgres would be nice, but Docker again gives an easy way of setting up “throwaway Postgresses”.
This all assumes Linux ofc.
Works fine for almost any team. Obviously it would be great if they would try to understand it, but it's really not necessary.
Not like most web devs know how most of the tools they use work (Source: All the teams I worked at)
Devs not knowing docker? Just install docker on their machine and ask them run the command above. One day has to be the first.
For simple apps I just run Postgres on the same server and size things appropriately in settings. It’s really not hard and it’s well-trodden territory.
If someone is making a single-tenant app that runs on an embedded device or something then SQLite is awesome.
The way this developer concludes that “most of you reading this” should use SQLite is very strange. Is that indicative of his audience building small or toy websites rather than actual production websites?
Most production websites are not multi million dollar businesses.
If you use an ORM from the beginning, you might not even have to change very much of your application code.
What I replaced it with was a Go binary with SQLite, where installing it would be a matter of installing the package or just the files and starting it up, it would take care of the rest.
SQLite is great for systems you don't control or have to set up, but maybe not for webservers. Common use cases are apps' internal storage (does not need to be shared with other applications or distributed), you don't want to have to install, configure and run MySQL or Postgres in those cases.
SQLite is fantastic, it absolutely should be used where appropriate.
I don't however understand those who argue that replacing the likes of PostgresQL / SQL Server with it is generally appropriate.
Now ... it didn't do anything but it was live and you could login, create users etc.
So ya, in process is faster for trivial stuff. But it's not faster when doing heavier workloads that benefit from things being in memory or having a better query planner.
The more you know :)
The query planner is still not nearly as good as PG's, but it's okay for simple applications.
I have actually used sqlite "at scale"... I'm still not sure people know that system (30k+qps dumping data into kafka) is running on sqlite on an EBS volume lol. But in this case it's just streaming stuff from disk, so pretty much any DB would have worked.
Your comment is basically the famous HN Dropbox comment but for databases: "are people really having problems getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem?"
Not a knock against SQLite at all, I use it in production for my own projects and some professionally as well.