4 ms·

Yes, when I said "production database" I meant a database for a web application. My iPhone running SQLite doesn't relate to Web 3.0.

• Closi 5y ago
  > Yes, when I said "production database" I meant a database for a web application 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).
  • luhn 5y ago
    I'm not sure how to parse what the author is saying besides you should be exposing your database directly, which is apparently SQLite. > 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.
  • netcan 5y ago
    I think he does mean web apps/sites, at least in large part. He is talking about implementing of web 3.0, after all. OTOH, I suppose there's no reason why web has to apply primarily to things that are currently webstuff. You both make good points.
  • dfabulich 5y ago
    I think you misunderstood the author. "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.
• root_axis 5y ago
  sqlite is actually quite robust in a production web application environment, I have used it as a database in several production applications over the years including one that serviced 600k MAUs without issue. if your application is very write heavy or you're FAANG scale it could present a problem, but IMO sqlite is probably the best bang for your buck solution for the workload of most websites and applications.
  • luhn 5y ago
    Yeah, I've heard the argument before that SQLite is just fine as a production database. Not arguing against that, just saying that it's not a common choice.
  • Groxx 5y ago
    tbh I wish it were used more. it's much cheaper to run and just as fast as mysql (sometimes much faster) on your average wordpress blog or equivalent. you don't need to handle thousands of concurrent writes, only maybe 5 max at peak... and queueing them for tens of milliseconds is totally fine. as long as you're not writing horrifically inefficient insert operations, you absolutely won't notice until you're under ridiculously high load for most sites.
• dspillett 5y ago
  SQLite is not uncommon in web applications. It isn't just found in phone apps and OSs. 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.
  • jrochkind1 5y ago
    I think you can just just refer to "non-nosql" as... sql! :)
    • dspillett 5y ago
      "nosql" tends to mean more than simply not SQL. Often not any sort of relational structure and related querying methods, for instance, so "not nosql" is not the same set of things as "SQL".
      • jrochkind1 5y ago
        And yet notably all the examples you listed are sql...
        • dspillett 5y ago
          And yet, you know that isn't the point and are just trying to have the last word. SQL is not the only structured query language and SQL-queried databases are not the only relational databases. It just happens that the subset of database services that are not nosql and commonly “compete” with sqlite as a relational database mostly happen to use some variant for SQL.
• regularfry 5y ago
  This whole architecture flips a lot of assumptions on their heads. In particular here, the assumption that all user queries end up in the same database instance, which then might not handle the load, is thrown out. Queries here are primarily local to, and potentially defined by, the user. If that's useful to you, it's not something you'd want to use a traditional MySQL or Postgresql setup for.