Hacker News new | ask | show | jobs
by TZubiri 736 days ago
In terms of installations, sure.

In terms of total data, probably not.

In terms of important data, 100% not. Important data needs guarantees, and its privacy is second to its longevity.

Server side and centralized beats client side decentralized for all but sensitive consumer data.

8 comments

You may be shocked to learn how much of the world's "important data" lives in Excel files.
A lot of world’s important data is on paper.

As far as important data served from a relational database is concerned, MySQL most likely beats the hell out of everything in terms of popularity. The bulk of SQLite’s usage has to be various runtime caches, file data, and so on.

Postgresql superseded mysql ever since the maria fork/oracle acquisition.
The topic is not quality but popularity.
Yes. In terms of popularity (installs/time) psql superseded mysql. Although of course at the tipover point msql still may have beaten psql in terms of total installations, i'm pretty sure even by that metric psql already won.
Source? I’ve only been using PostgreSQL, but I believe most legaxy systems are not going to rush to update, and world consists of legacy systems and systems that will become legacy tomorrow.
Fun fact: my (french) company audited the french navy and found out they share important nuclear submarine maintenance data as excel files through email.
Former US military officer here. This does not surprise me at all. I wasn’t in subs but we absolutely did this for maintenance of other multimillion dollar assets.
Microsoft is in so many government offices around the world it's not even funny.
I’m certain MS is in all government offices almost globally, except that one municipality in Germany that keeps attempting a Linux transition every other year.
Not shocked, not a problem.

Easier to copy/replicate, packaged with a GUI, provider with a commercial relationship, programmatic support ( formulas, vba, COM, raw data access)

Would be closer to sqlite than server side though, but it's capacity for replication and sharing makes it more adecuate for sqlite.

Sqlite's lack of GUI gives data a programmer bias, important data uses excel because unless you are in a technocratic environment.

There's quite a few guis available, eg here's mine: https://www.timestored.com/qstudio/database/sqlite You raise an interesting idea. What if sqlite database s has also been .exe executable to give at least a cli. That would have been interesting, similar to redhead.
I'm not sure I buy the "important data" one: my Lightroom catalog, to me, constitutes incredibly important data. Losing it and just having the base files would destroy over a decade of work.

It also happens to be a SQLlite3 database. And the same is true for a slew of other applications that (quite rightly) use SQLite databases as their file format.

You might be thinking of things like financial transactions, or medical records, but that's not the only kind of important data there is.

The number of societal-wide problems that occur if your Lightroom database gets corrupted is zero.

The amount of hell that would be unleashed if the financial systems layers upon layers of database transactions got broken is impossible to comprehend.

So if you mean “important” as “necessary for society to function”, then no, your browser bookmark files, contact list, or the other two dozen things your laptop and phone use SQLite for are not important.

This is a false equivalence, as one user’s particular usage of SQLite is not comparable to all financial instructions’ databases.

Better to compare to the prospect of all smartphones being irreversibly corrupted at once.

Literally all smartphones dying at once is preferable because they are all backed up into heavy duty databases. You can restore every phone from the cloud in this thought experiment.

You can not restore a data center from a pile of phones.

The goalposts keep moving here. You can just take any arbitrary definition of important and use it to exclude SQLite deployments.

It's all semantics, and also irrelevant to the original article anyway, since nowhere does it argue that SQLite holds the most data (important or otherwise).

I didn’t comment earlier so I can’t move a goalpost I never set down. I agree with the root comment that there may be more instances of SQLite, the most important data is not in SQLite.

For what it’s worth, I have used any number of databases over the years and SQLite is very good for a number of things.

None of those things are the core infrastructure that stores your emails, money, and other must have, shared, high availability data.

There are different tools for different jobs, that’s fine.

How do you physically store it? An external disk?

I venture a guess that for each sqlite db holding important work data, you have dozens or hundreds of traditional db datasets, that are critical to your work. And yes, I mean your bank, but also messaging apps, online services.

If you backup your hard drive in the cloud at all, you are already depending on trad dbs for the very use case supposedly highlighting your dependence on sqlite.

+1

So is contacts list, sms messages, Whatsapp data, browser data etc etc. whese are separate installations of sqlite, hundreds per phone. And they ARE important, at least to me.

Interesting.

My contacts are stored in my sim chip or google(server), also they are shared with many apps (server), whatsapp msgs are backed up to google drive (server), and itself stored on server side whatsapp servers.

Broswer data is sqlite yes, but it is also flushed every couple of months, and is by design ephemeral.

How would you go about measuring that, or determining what's important?

Huge SQL for servers is just a different use case.

Someone's temporary browser data or settings for my android alarm app could be just as important and sensitive as an average record on those big servers.

Fortunatelly, SQL fits the role of a small transactional engine very well to support those small use cases for a large number of applications. It deserves the good reputation.

We don't need to measure everything, we may talk about variables that are hard or subjective to measure.
Right. In terms of installations, I bet textfiles still win. Doesn't mean much, does it?
Gross theoretical error. Text files are a (ambiguous and undefined) file format, while sqlite is an application.
> In terms of total data, probably not.

> In terms of important data, 100% not.

Choosing not to focus upon quantity or quality is likely the reason why SQLite is so popular. It is a lot easier to manage and develop for SQLite than it is to do the same for large databases that require high availability and reliability under heavy loads. There are many more applications for small databases that contain data that is important to the end user even though that data may not be important to anyone else.

You can also use a plain file system, it allows data to be exported more easily and through un unbiased app like a file explorer.

I'd say if the data is important and client side, you'd probably want it to be accesible in a protocol format rather than a sqlite file format.

It's cool that sqlite is open source and u can technically recover the data, but at the end of the day excel data is more accesible, which defeats the ethos of open sourceness

Would you classify a nurse call system as requiring important data retention and access? Mapping backbone devices with passive and interactive end user devices with means to communicate whom should provide assistance?

Works great there too with μC/OS-II. Competition was using Windows XP and Microsoft Access.

Only time ever using Oracle has been with internal business analytics, not very important.

No I would not, the application is important and critical, but the data? What data are you holding? Historical auditable data regarding calls? I have some experience with hospitals, and deep data like this would never be used for diagnostics or even epidemiology tracing.
> Server side and centralized beats client side decentralized

SQLite works on the server too. Important data can live in a SQLite database.

I remember reading or seeing this post about how SQLite can really scale and supports a really high amount of transactions per second. I don't know if it supports distrubuted loads that well, which might be the reason why it's use didn't pick up server side.