4 ms·

The point is that choosing what appears to be wrong tool for the job and putting a bunch of engineering effort into it makes no sense unless you can demonstrate

by hobs 3y ago

The point is that choosing what appears to be wrong tool for the job and putting a bunch of engineering effort into it makes no sense unless you can demonstrate some special something that makes it all worth it. Sqlite is very nice and frankly I love using it, but its data types, features, indexes, really everything is just a simplified version of all the of the more enterprise grade databases. Heck, some of them are even free and open source, run in a container, and (as I said) have decades of bug fixes and solutions to difficult weird replication bugs and performance regressions from their various features they added. Like with any new solution, its on the people presenting it to proffer why its better, and the marketing spin seems like you get a vendor specific extension to a thing that ties you to them forever, not so great for data that might live for decades!

kjksf 3y ago
If your job requires something that SQLite doesn't provide, then sure, that's the wrong tool for the job. But SQLite is literally the most frequently used database in the world so it clearly is the right tool for a large number of jobs. It's a very fast and very capable database and the reliability is unmatched (because it has been the most tested and because Richard Hipp wrote more tests than anyone else). There's this persistent myth that SQLite is some rinky dinky toy for toddlers. I repeat: it's very fast, very capable database, more than capable of addressing 97% of the needs of people who use sql databases. What bothers me about this kinds of "SQLite is not the right tool" assertions is a complete lack of any supporting evidence. Like, give me an example of something that you're doing where Postgres or MySqlite offers meaningful improvement over SQLite. I'm not saying those cases do not exist, just that they are much rare that people tend to assert and you haven't provided a single example. Pieter Levels runs highly profitable, highly trafficked website (Nomad List) on sqlite and he doesn't even write joins. And my point is that you vastly overestimate the need for super duper advanced functionality in databases. Lots of apps were written on top of early MySQL, which was a joke in terms of both capabilities and reliability. SQLite today is more capable and reliable that MySQL was for a long time.
- hobs 3y ago
  I didn't underestimate anything really, I am supposedly an expert in the field. I have used 100GB+ workloads on sqlite, its great, its useful, and its still extremely limited compared to the featuresets of other mutli-user relational databases. Oh, and the "and he doesn't even use joins" doesn't really show that sqlite is great at anything, its materially more difficult for a query planner when joins come into play, its the normalization and deduplication benefits (which can play into performance benefits at certain scales) that make a join useful.
- claytongulick 3y ago
  > Like, give me an example of something that you're doing where Postgres or MySqlite offers meaningful improvement over SQLite. alter table foo alter column bar type varchar(10); [1] [1] https://www.sqlite.org/lang_altertable.html https://www.sqlite.org/lang_altertable.html

by hobs 3y ago

kjksf 3y ago

If your job requires something that SQLite doesn't provide, then sure, that's the wrong tool for the job. But SQLite is literally the most frequently used database in the world so it clearly is the right tool for a large number of jobs. It's a very fast and very capable database and the reliability is unmatched (because it has been the most tested and because Richard Hipp wrote more tests than anyone else). There's this persistent myth that SQLite is some rinky dinky toy for toddlers. I repeat: it's very fast, very capable database, more than capable of addressing 97% of the needs of people who use sql databases. What bothers me about this kinds of "SQLite is not the right tool" assertions is a complete lack of any supporting evidence. Like, give me an example of something that you're doing where Postgres or MySqlite offers meaningful improvement over SQLite. I'm not saying those cases do not exist, just that they are much rare that people tend to assert and you haven't provided a single example. Pieter Levels runs highly profitable, highly trafficked website (Nomad List) on sqlite and he doesn't even write joins. And my point is that you vastly overestimate the need for super duper advanced functionality in databases. Lots of apps were written on top of early MySQL, which was a joke in terms of both capabilities and reliability. SQLite today is more capable and reliable that MySQL was for a long time.

hobs 3y ago
I didn't underestimate anything really, I am supposedly an expert in the field. I have used 100GB+ workloads on sqlite, its great, its useful, and its still extremely limited compared to the featuresets of other mutli-user relational databases. Oh, and the "and he doesn't even use joins" doesn't really show that sqlite is great at anything, its materially more difficult for a query planner when joins come into play, its the normalization and deduplication benefits (which can play into performance benefits at certain scales) that make a join useful.
claytongulick 3y ago
> Like, give me an example of something that you're doing where Postgres or MySqlite offers meaningful improvement over SQLite. alter table foo alter column bar type varchar(10); [1] [1] https://www.sqlite.org/lang_altertable.html https://www.sqlite.org/lang_altertable.html