Why even write this? It's yet another convoluted use of the term and meaningless for SQLite of all things.
Re: downvotes - what are people disagreeing with? That the term is not convoluted? That it's actually useful? That it helps to have more sub-definitions in an industry known for overloaded terms? I guarantee not a single person here has used "classic serverless" over "in-process" or "embedded" in their entire career.
Adding an original timestamp to the page would've been more helpful than the updated section, or just deleting the page entirely. Or just title it as "SQLite is not client/server".
Nobody goes around talking about "classic serverless" instead of "in-process" which has been around for decades.
The article is from 2007, and explicitly calls out that the "neo" usage of the term is different than the original. If you scroll to the fifth line or so, you'll find the update. I didn't have to scroll on my device, though i can imagine there are some smaller devices that may not have that line on the screen when opening the page.
Where does it say 2007? Regardless it's vague and irrelevant material.
Classic serverless has always been known as "in-process". The attempt at differences seems like adding marketing fluff rather than just removing the page entirely.
It's not vague at all, the term makes sense to distinguish "in-process" from client/server models. The page also includes an explanation on the very next line.
> Adding an original timestamp to the page would've been 100x more helpful
Not everyone reading about a database product is a developer. A timestamp would not help anyone unfamiliar with the history of the serverless term. The alternative is to rewrite all instances of "serverless" in the documentation which is a waste of time. Modern "serverless" is a stupid buzzword and this page clearly serves as a protest.
> I would love to know who uses "serverless" instead of "in-process". Why add a new term at all?
"In-process" is meaningless to non-IT people, they don't even know what a process is. The SQLite dev probably created the term for marketing purposes, i.e. the exact same reason cloud providers adopted it 10 years later.
> And if the definition has since been muddied, then all the more reason to avoid using it instead of creating even more niche definitions.
I disagree. The term in relation to SQLite is clearly defined and predates the modern version, there's really no need to go back and change it. You're also disregarding the statement made by the SQLite dev by keeping this page and updating it with a clarification.
Those people wouldn't end up on a random documentation page for SQLite then, making this argument superfluous.
> I would love to know who uses "serverless" instead of "in-process". Why add a new term at all?
This discounts which term came first. Back in 2007 it was just fine to talk about this as being serverless, the marketing term gained popularity years later. They even talk about the more recent definition on the page, I really don't get why people in this sub thread get triggered by some random documentation page written over a decade ago. There's no need to further change or delete that page because this discussion is lacking any practical relevance.
Non-IT people make IT decisions all the time. If you can sell your IT product to C-levels, they'll force IT to use it. Look at how companies misuse things like blockchain, ML and AI just because of the hype around those words.
Yea, that's now how SQLite has ever been sold. All the other comments on this post have since shown just how useless the "serverless" label is for this.
I have seen that page for around 10 years or so (except the section that was added in 2018). The term has a very clear meaning and consistent uses within the docs (and consistent with my common sense understanding of the word too). It is not SQLite's fault that AWS and co muddles the water with their usage of the term
Actually seems more like the original than yet another. And also it makes more sense “serverless” as in “there is no server” and not as in “someone else manages the server for you”.
The same reason supermarkets put "gluten free" on things like butter, water and vegetables. While it may seem stupid and obvious to those informed and educated, theres a point in everyones life where they dont know anything about a subject and they need a first step. Hopefully, its a first step in a deeper understanding and education on the subject at hand.
I'm sure people will google stuff like "Is SQLite serverless?". There are no such thing as stupid questions, you're only stupid if you choose not to learn.
Wouldn't it be better to say "SQLite is an embedded database and not client/server". Easily understood using very well-known and absolutely clear terms.
Saying "serverless" is trying to sum up that definition into a single word. It wasn't that useful back then and now has been further overloaded. Who is going to google "serverless" today and learn about SQLite's meaning of it?
I mean i dont really like the term serverless at all anyway, as its meaning isnt really literal, its more literal and correct in the context of SQLite IMO. Unfortunately thats just the world we live in. It also annoys me that the word "literally" now has a secondary definition in the dictionary to mean figuratively, just gotta get used to it, despite my dislike for it.
Meanings and definitions of words change over time as they get used. Another prime example would be the word "Hacker".
It is not meaningless, but perhaps unclearly expressed.
There is a fundamental point the the argument: you can distribute a database without segregating it.
Three methods to building a 1M+ users webapp:
1. A centralized database, eg. PostgreSQL. Typically it has a single-writer beefy machine.
2. A decentralized newSQL. Tables are automatically sharded for writes, among a set of database-only servers. Typically offered as cloud: CosmosDB, Cloud Spanner, Aurora.
3. A distributed system segregated per app. Each user has a dedicated sqlite file.
The third option would be simpler to code for, since it won’t have substantial scaling issues.
It is also easier for a lambda-like platform to provide: load the sqlite corresponding to the authenticated user, and the lambda code, and execute the code in sandbox.
Although one negative aspect for the AWS of this world would be lack of lock-in. It is relatively easy to migrate to another cloud service, or to mix cloud services.
Re: downvotes - what are people disagreeing with? That the term is not convoluted? That it's actually useful? That it helps to have more sub-definitions in an industry known for overloaded terms? I guarantee not a single person here has used "classic serverless" over "in-process" or "embedded" in their entire career.