5 ms·

It's not sarcasm. The fact that it's a library and you point it at a file matters, and should be thought about. It implies that it's not built for distributed s

It's not sarcasm. The fact that it's a library and you point it at a file matters, and should be thought about. It implies that it's not built for distributed systems. It's not supposed to be a managed service. It's not a good option for what you appear to want. You deploy it as part of your application.. it's a library.

sanderjd 4y ago
> It's not a good option for what you appear to want. Ok but the article you're replying in the comments to says "SQLite is all you need for nearly everything", and what the comment you're replying to is describing is, to use their very apt word choice, entirely ordinary. So how do we square this circle of somebody being told both "SQLite is all you need for everything" and "it is not a good option for your totally ordinary use case"? I think the answer is that you are a different person than the author of the article and you don't agree with the article's claim. Which, great, that was irskep's entire point! I tend to agree with irskep that this SQLite architecture is really interesting, but I also don't quite get it. There seem to be a lot of missing details for totally bog standard applications, that people frustratingly seem to just not even mention - like the migrations thing, or how to do zero downtime deploys in general, or a few other things - as if those concepts are irrelevant or uncommon. But they aren't, they're important and typical things to think about.
- danielmarkbruce 4y ago
  Third paragraph of the article says: "In contrast to many other database management systems, SQLite is not a client-server database engine, but you actually very rarely need that. If your application software runs on the same physical machine as the database, which is what most small to medium sized web applications does, then you probably only need SQLite." That's how we square it. It's right there in the article.
  - butlerm 4y ago
    That is a claim, not an explanation. Satisfactory answers need to be provided for the typical requirements that a small to medium web app might have, or the claim is unjustified. (Nearly) zero down time is a common requirement. Can a live backup be made while transactions are in progress? That appears to be the case. What about schema changes? Can columns or indexes be added without interfering with access to the tables in question? And so on.
    - rakoo 4y ago
      > (Nearly) zero down time is a common requirement. Are we still talking about small to medium web apps ? I'm sorry but if HN goes down things will be OK. In fact, there is a very large majority of services that can go down go down and things will still be OK.
  - sanderjd 4y ago
    I've realized that this whole thing comes down to the word "most" doing too much duty here. I don't think it's true that most applications just run a single db-and-application node. I've never worked on such an application. You and the author do seem to think this is true. It would be difficult for either of us to support our intuition empirically, so this is where the divide comes from.
    - danielmarkbruce 4y ago
      Yep, that's probably true.
    - naniwaduni 4y ago
      > I don't think it's true that most applications just run a single db-and-application node. I've never worked on such an application. Rather than applications you've worked on (many of us spend years on end working on a narrow range of applications), consider software you use (most of us flip between multiple applications every day spanning the gamut of uses). Ignore, for a moment, whatever you know about their implementation, and focus on the user-facing functionality. Do even half of them logically communication between application nodes? (Consider that there is still a rich class of software that is fully capable of running locally on the "client"'s computer!)
      - sanderjd 4y ago
        Yes I think pretty much all the applications I interact with require fault tolerance and uptime that (to me) seems simpler to implement with separation between application and database nodes.
        mharig 4y ago
        So you do not interact with - Browsers - Messengers - The telephone directory of your cellphone - SMS apps - The sqlite.org Website - ... ?
- pastor_bob 4y ago
  Distributed databases are rarely needed. I wouldn't call it an ordinary use case. The article isn't claiming Elon Musk can run Twitter off SQlite
  - sanderjd 4y ago
    It is honestly difficult for me to imagine what kind of applications people are working on that have these - to me - very lax reliability constraints. But we're just disagreeing over what "most" applications are like, based on our experiences, without any empirical data to say either way, so :shrug:.
    - yawaramin 4y ago
      WordPress is the obvious example of an application that can run like 99% of instances just fine with SQLite.
      - sanderjd 4y ago
        Interesting!
    - bravura 4y ago
      Off-the-top of my head. * Hobby apps designed for yourself and your friends. * Hobby apps that you hope will become products but probably won't achieve traction. * Apps where you're trying a new stack or framework. * Annotation apps for academia. Basically, every single app written by people who aren't doing internet facing web dev as their core engineering function. Also intranet apps as other commenter mentioned.
      - sanderjd 4y ago
        When I read an article like this that claims some architectural technique is broadly applicable, I don't think it is talking about hobby or just-for-learning applications. Certainly you can do whatever you want with those, but that's not very illuminating. I'm not sure exactly what you have in mind for annotation apps for academia - things like zotero that run client side? If so, sure, there is a big world of client side software where a database is useful, and I think SQLite (or DuckDB) seems like a no brainer there. I don't really agree about intranet apps, which are often even more critical to the people using them than an arbitrary consumer app. But I'll grant that for a company that spans a small number of time zones, you can at least have downtime windows outside work hours. In any case, as I've said all over this thread, the only disagreement here is over what kinds of software is "most". And my intuition for "most" is based on my experience working on and using applications where a lot of effort is made to keep the thing running all the time while still evolving it. Maybe you're all right that "most" software isn't like that.
- chillfox 4y ago
  Most things don't need zero downtime deployment. Now it's nice to have and might be an interesting technical challenge to solve, but it's usually not strictly needed. edit: when I worked as a sysadmin we would have to schedule outages for updating apps that were designed for zero downtime anyways because those were the processes of the organisation.
  - maxthegeek1 4y ago
    What? I've never worked for a company that would tolerate downtime during deployments. Downtime is ok for personal projects, but not for most business applications.
    - chillfox 4y ago
      Most business have daily downtime where the entire business is closed as in not business hours. Being sensitive to downtime is more common for companies that has some kind of online service as their primary product, but most companies are not online companies, or even global companies with offices across all the time zones. Even for online business some downtime might be acceptable or even preferred. I used to work for a company that made most of it's money through a website and it would take the site offline for 8 hours a few weeks before important events to run a full scale load test on the production infrastructure. Another place I worked we had to schedule downtime even when updating applications that were designed for zero downtime. I have never worked a place that didn't allow for downtime or even heard of such a place other than the big tech companies.
      - fomine3 4y ago
        scheduled maintenance downtime at night != unplanned failure downtime at random time
        chillfox 4y ago
        Correct, but in the context of deploys I would hope they are not random failures, but rather planned events that you do when you have updates to... deploy.

sanderjd 4y ago

> It's not a good option for what you appear to want. Ok but the article you're replying in the comments to says "SQLite is all you need for nearly everything", and what the comment you're replying to is describing is, to use their very apt word choice, entirely ordinary. So how do we square this circle of somebody being told both "SQLite is all you need for everything" and "it is not a good option for your totally ordinary use case"? I think the answer is that you are a different person than the author of the article and you don't agree with the article's claim. Which, great, that was irskep's entire point! I tend to agree with irskep that this SQLite architecture is really interesting, but I also don't quite get it. There seem to be a lot of missing details for totally bog standard applications, that people frustratingly seem to just not even mention - like the migrations thing, or how to do zero downtime deploys in general, or a few other things - as if those concepts are irrelevant or uncommon. But they aren't, they're important and typical things to think about.

danielmarkbruce 4y ago
Third paragraph of the article says: "In contrast to many other database management systems, SQLite is not a client-server database engine, but you actually very rarely need that. If your application software runs on the same physical machine as the database, which is what most small to medium sized web applications does, then you probably only need SQLite." That's how we square it. It's right there in the article.
- butlerm 4y ago
  That is a claim, not an explanation. Satisfactory answers need to be provided for the typical requirements that a small to medium web app might have, or the claim is unjustified. (Nearly) zero down time is a common requirement. Can a live backup be made while transactions are in progress? That appears to be the case. What about schema changes? Can columns or indexes be added without interfering with access to the tables in question? And so on.
  - rakoo 4y ago
    > (Nearly) zero down time is a common requirement. Are we still talking about small to medium web apps ? I'm sorry but if HN goes down things will be OK. In fact, there is a very large majority of services that can go down go down and things will still be OK.
- sanderjd 4y ago
  I've realized that this whole thing comes down to the word "most" doing too much duty here. I don't think it's true that most applications just run a single db-and-application node. I've never worked on such an application. You and the author do seem to think this is true. It would be difficult for either of us to support our intuition empirically, so this is where the divide comes from.
  - danielmarkbruce 4y ago
    Yep, that's probably true.
  - naniwaduni 4y ago
    > I don't think it's true that most applications just run a single db-and-application node. I've never worked on such an application. Rather than applications you've worked on (many of us spend years on end working on a narrow range of applications), consider software you use (most of us flip between multiple applications every day spanning the gamut of uses). Ignore, for a moment, whatever you know about their implementation, and focus on the user-facing functionality. Do even half of them logically communication between application nodes? (Consider that there is still a rich class of software that is fully capable of running locally on the "client"'s computer!)
    - sanderjd 4y ago
      Yes I think pretty much all the applications I interact with require fault tolerance and uptime that (to me) seems simpler to implement with separation between application and database nodes.
      - mharig 4y ago
        So you do not interact with - Browsers - Messengers - The telephone directory of your cellphone - SMS apps - The sqlite.org Website - ... ?
pastor_bob 4y ago
Distributed databases are rarely needed. I wouldn't call it an ordinary use case. The article isn't claiming Elon Musk can run Twitter off SQlite
- sanderjd 4y ago
  It is honestly difficult for me to imagine what kind of applications people are working on that have these - to me - very lax reliability constraints. But we're just disagreeing over what "most" applications are like, based on our experiences, without any empirical data to say either way, so :shrug:.
  - yawaramin 4y ago
    WordPress is the obvious example of an application that can run like 99% of instances just fine with SQLite.
    - sanderjd 4y ago
      Interesting!
  - bravura 4y ago
    Off-the-top of my head. * Hobby apps designed for yourself and your friends. * Hobby apps that you hope will become products but probably won't achieve traction. * Apps where you're trying a new stack or framework. * Annotation apps for academia. Basically, every single app written by people who aren't doing internet facing web dev as their core engineering function. Also intranet apps as other commenter mentioned.
    - sanderjd 4y ago
      When I read an article like this that claims some architectural technique is broadly applicable, I don't think it is talking about hobby or just-for-learning applications. Certainly you can do whatever you want with those, but that's not very illuminating. I'm not sure exactly what you have in mind for annotation apps for academia - things like zotero that run client side? If so, sure, there is a big world of client side software where a database is useful, and I think SQLite (or DuckDB) seems like a no brainer there. I don't really agree about intranet apps, which are often even more critical to the people using them than an arbitrary consumer app. But I'll grant that for a company that spans a small number of time zones, you can at least have downtime windows outside work hours. In any case, as I've said all over this thread, the only disagreement here is over what kinds of software is "most". And my intuition for "most" is based on my experience working on and using applications where a lot of effort is made to keep the thing running all the time while still evolving it. Maybe you're all right that "most" software isn't like that.
chillfox 4y ago
Most things don't need zero downtime deployment. Now it's nice to have and might be an interesting technical challenge to solve, but it's usually not strictly needed. edit: when I worked as a sysadmin we would have to schedule outages for updating apps that were designed for zero downtime anyways because those were the processes of the organisation.
- maxthegeek1 4y ago
  What? I've never worked for a company that would tolerate downtime during deployments. Downtime is ok for personal projects, but not for most business applications.
  - chillfox 4y ago
    Most business have daily downtime where the entire business is closed as in not business hours. Being sensitive to downtime is more common for companies that has some kind of online service as their primary product, but most companies are not online companies, or even global companies with offices across all the time zones. Even for online business some downtime might be acceptable or even preferred. I used to work for a company that made most of it's money through a website and it would take the site offline for 8 hours a few weeks before important events to run a full scale load test on the production infrastructure. Another place I worked we had to schedule downtime even when updating applications that were designed for zero downtime. I have never worked a place that didn't allow for downtime or even heard of such a place other than the big tech companies.
    - fomine3 4y ago
      scheduled maintenance downtime at night != unplanned failure downtime at random time
      - chillfox 4y ago
        Correct, but in the context of deploys I would hope they are not random failures, but rather planned events that you do when you have updates to... deploy.