Comment by bane | Hacker News Reader

Comment by bane | Hacker News Reader

Parent Full thread

> and I think I've always approached it "from a classic RDBMS angle"

Have you tried to figure out where to install the server or asked what the system requirements were for it?

Have you grown concerned that once the system moves into production the O&M team won't know how to operate "yet another database"?

Do you spend agonizing hours trying to figure out if it supports multithreaded connection pools for multi-user writes?

Have you wondered if your organization has the budget to add another DBA to the team if you add SQLite to your tech stack?

If the answer is no to all of the above you aren't approaching it from a classic RDBMS angle. Believe it or not, there are tens of thousands of questions about SQLite struggling to figure out the answer to the above questions.

The people asking these questions are not stupid, they're just approaching the technology from the wrong direction.

This post is no different than "CSV is serverless" or "JSON is server-less" with a blog post about classic vs neo-serverless JSON technologies.

> Have you tried to figure out where to install the server or asked what the system requirements were for it?

Not exactly, but asking "where to install the server & client and what are the system requirements for each" is not that different to asking "where to install the client and what are the system requirements for it", even when there is no server.

> Have you grown concerned that once the system moves into production the O&M team won't know how to operate "yet another database"?

Yes. Because the production concerns of SQLite are not nil.

> Do you spend agonizing hours trying to figure out if it supports multithreaded connection pools for multi-user writes?

Not agonizing hours, but it is just a slightly rephrased version of a valid question about SQLite w.r.t. concurrent file access (as with locks on file access for any file). Other commenters have brought this up in terms of multi-user access slowing down applications, and setting up intermediary DB access processes using IPC to facilitate this.

> The people asking these questions are stupid

I disagree

> no different than "CSV is serverless" or "JSON is server-less"

CSV and JSON lack any protocol or queryable interface: unless you're using some ancillary tool like `jq` as a comparison, CSV and JSON as filetypes are both "serverless" and "clientless" so not particularly comparable. An article on those would be quite different.

bane said "not stupid"

That was a later Edit. The original did not have the word "not".

I make these errors sometimes too and need to edit. HN's method beats Twitter, but it would be nice if we could see a versioned history of each message...

The original document is from SQLite documentation. I think it’s fair for them to make a case why sometimes a file database > a server database. People asking these questions are not stupid. We all have to start somewhere.

Please check it again, I wrote "not stupid".

The SQLite creators have a great deal of documentation that's targeting database administrators and users and trying to explain what this thing is, when I think they really should have just targeted people who need a nice file format and a clean API.

But hell, there's like a trillion SQLite files in use so what do I know?

Reply on news.ycombinator.com