I'm not sure that's what the author of the article means though, at least in my interpretation.
I assume when they say "everyone is already using it" I assumed that they meant literally everyone is using it on their phones and PCs every day, not that everyone is using it to develop production web applications (because very few people develop production web applications in the grand scheme of things!).
I presume they mean that it is one of (if not the) most common databases in existence in the wild, and it's interesting that it has this property of being able to be remotely read with surprisingly little overhead (without the need to implement an entirely bespoke database to be read in this way).
> In the process, it demonstrated a new kind of web app whose entire database was exposed and queryable from the outside.
> The data needs to be exposed in its original form; any additional translation step will ensure that most people won't bother.
"The data needs to be exposed in its original form; any additional translation step will ensure that most people won't bother. The beauty of this technique is that you are already using SQLite because it's such a powerful database; with no additional work, you can throw it on a static file server and others can easily query it over HTTP."
The author believes (IMO wrongly) that there's lots of web app data that can be exposed via SQLite-over-HTTP without translating it into SQLite, because it's already in SQLite.
The author is saying that since lots of web apps use SQLite for their production database, they can easily "throw" their SQLite DB onto the web. But, in that case, you're out of luck if you use Postgres, MySQL, Oracle, MS SQL Server, or any of the popular key-value datastores like Mongo, Redis, or Elasticsearch.
It works pretty well for tasks that are primarily read heavy and is a lot lighter doing so than the common non-nosql alternatives (SQL Server, postgres, mariadb/mysql, ...). For applications that need good performance in the presence of much writing, particularly where concurrent writes might be desirable, it is far less ideal though.
