> SQLite can work well for the parts of your system where there is naturally strong partitioning.
replyOr the parts of your system that don't have big data and no need for massively concurrent writes. And that's the vast majority of systems!
You can do big data in SQLite. Concurrent writes, sure, I'd recommend something else.
replyIf you think the majority of systems require massively concurrent writes, I think you need to look a bit harder. SQLite is, after all, the most widely deployed database system, ever.
Internet Explorer 6 was the most widely deployed awesome piece of software. Those that hated it need to look a bit harder.
replyIt was not really “deployed” by a lot of people in the same sense.
replyIt was forced upon most of us(not me, I used BeOS then Debian then FreeBSD).
I deployed phoenix.
The reason SQLite is the most deployed is that it's used by Android.
reply…and iOS, and Windows, and Mac OS, and Boeing, and Sony, and Firefox and Chrome and Safari…
replyYes, which goes in line with the argument that claiming that it's "the most deployed" as proof of superiority or suitability for any use case is equivalent to claiming the same for Internet Explorer. It's the most deployed because it's bundled in a lot of systems, not because people are purposefully using it as a DBMS.
replyIt’s widely deployed as a local DB for local apps like phones, desktops, and web browsers. But it’s not the most used for distributed, concurrent web apps, which db servers were designed for. Maybe people are talking past each other, but that’s the debate I see.
replyNot sure why there’s a debate at all. The discussion is on using SQLite instead of jq and markdown files. People got lost on a tangent! :)
replyNo it's not.. the context of other threads on this post (which mention jq) do not apply here. How poorly coded are you?
replyLike how poorly did Jesus code my DNA? Ask him. By him I mean ChatGPT Jesus mode.
replyWe recently just partitioned the data into many SQLite databases and got away with it. It's telemetry data from IoT devices: one device, one database. Backups are an easy rsync job now instead of streaming a multi gigabyte database with compression that take hours. Reporting will just open each database and aggregate multi device data into another database (Duckdb, SQLite or something else, we'll see). Duckdb is not readable when locked so it's probably also going to be SQLite. Even it it's going to spit out JSON it will go into SQLite rows instead of many files.
replyCheck out Quack for DuckDB.
replyWhat additional skill set do you need to "learn" for SQLite? Copying files around?
reply