5 ms·

TL;DR because it's simple.

by jbob2000 7y ago

umvi 7y ago
Is it simple, though? I mean, reading about how they test it[1] leads me to believe it is not simple. Maybe it's simple compared to Oracle, and maybe using it is simple, but the actual implementation is definitely not simple. [1] https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
- jbob2000 7y ago
  I don't care about the implementation and I congratulate the developers on abstracting all of that complexity away from me. That's what good software does.
  - umvi 7y ago
    I misinterpreted your comment. I thought you were saying SQLite was successful because SQlite itself (i.e. the implementation) was simple, not because it was simple to use.
    - wpietri 7y ago
      For what it's worth, I use "simple" for talking about the complexity of the thing, and "easy" for the user experience. Quite frequently easy things have to be complex because the cognitive load gets shifted into the machinery. E.g., compared with a Model T, modern cars are much easier but much more complex because the car itself understands things like adjusting the ignition timing and safely getting the motor turning, things that a Model T user had to understand if they wanted to avoid getting a broken arm before they got out of the driveway: https://www.fordmodelt.net/how-to-drive-ford-model-t.htm https://www.fordmodelt.net/how-to-drive-ford-model-t.htm
- solarkraft 7y ago
  It's simple to use.
  - umvi 7y ago
    Most of the time, yes, if SQLite supports the filesystem you are using. If the filesystem doesn't have a particular feature SQLite needs, it can be difficult to get working the way you want it to.
    - danso 7y ago
      What scenarios/filesystems lead to these kinds of conflicts?
      - franga2000 7y ago
        Not exactly a filesystem, but it doesn't work on SMB shares, which is an enormous pain in the ass. And I'm not even talking about concurrent access - just one user. I get that SMB file locking is a mess, but making it a hard fail by default was a big mistake IMO as most develoers using the library don't make special cases to allow this.
        nomel 7y ago
        The documentation is very clear than SQLite over a network isn't a good use case, for reasonably sized data. Item 1 from "Checklist for choosing the right database engine" [1] > 1. Is the data separated from the application by a network? → choose client/server > Relational database engines act as bandwidth-reducing data filters. So it is best to keep the database engine and the data on the same physical device so that the high-bandwidth engine-to-disk link does not have to traverse the network, only the lower-bandwidth application-to-engine link. > But SQLite is built into the application. So if the data is on a separate device from the application, it is required that the higher bandwidth engine-to-disk link be across the network. This works, but it is suboptimal. Hence, it is usually better to select a client/server database engine when the data is on a separate device from the application. 1. https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html
      - umvi 7y ago
        Well the issue I ran into was that I wanted a SQLite db to have one writer and many readers. However, what I was seeing was that queries were failing because the DB was locked at the time of reading. The solution is to switch journaling mode to WAL[1]. However the particular platform I was developing for was an embedded system using the JFFS2 filesystem. JFFS2 doesn't support shared mmap, which is a feature SQLite needs for WAL. So basically, it was big pain - I had to setup a tmpfs mount point where the WAL-enabled DB resided and then periodically sync it to flash. [1] https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html
- scottlamb 7y ago
  > I mean, reading about how they test it[1] leads me to believe it is not simple. They are unusually thorough in their testing. I see that as a good thing, not a sign it isn't (relatively) simple. In fact, I don't think any other database engine is tested as thoroughly. I can't even imagine how much effort it'd take to do so for Oracle or even PostgreSQL, except that it'd be prohibitive.
gwd 7y ago
I'd say there are a load of reasons, all of which combine together to make it unbeatable: * Simple to embed into you application (no setting up a separate database, &c). * Fantastically backwards compatible * Public domain (so easy to comply with the license) * High quality: Reasonably fast, reasonably efficient, reasonable feature support. The lack of any of these would add significant drag. It's difficult to imagine any other project catching up and displacing it at this point.
- bob1029 7y ago
  I personally cannot see any near term replacement for what SQLite offers. In my world, SQLite became the way in which I now manipulate a scope of structured data on a single logical disk. I mostly view it as a very reliable and friendly layer on top of basic file IO which also happens to be compatible with virtually every computer on earth. I can copy a SQLite database out of an embedded microcontroller environment and directly open it on my x86_64 workstation, edit some values, and then copy it back down without any fears of compatibility issues.
thrower123 7y ago
I do wonder how much of the time that SQLite is used, that it wouldn't be even simpler to just dump things to an XML file.
- lurker458 7y ago
  Here are some considerations why: https://danluu.com/file-consistency/ https://danluu.com/file-consistency/
  - xolox 7y ago
    Thanks for sharing that link, it's on the most valuable things in this thread for me! (I loved SQLite already and one HN thread more or less isn't going to change that)

TL;DR because it's simple.

umvi 7y ago

Is it simple, though? I mean, reading about how they test it[1] leads me to believe it is not simple. Maybe it's simple compared to Oracle, and maybe using it is simple, but the actual implementation is definitely not simple. [1] https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html

jbob2000 7y ago
I don't care about the implementation and I congratulate the developers on abstracting all of that complexity away from me. That's what good software does.
- umvi 7y ago
  I misinterpreted your comment. I thought you were saying SQLite was successful because SQlite itself (i.e. the implementation) was simple, not because it was simple to use.
  - wpietri 7y ago
    For what it's worth, I use "simple" for talking about the complexity of the thing, and "easy" for the user experience. Quite frequently easy things have to be complex because the cognitive load gets shifted into the machinery. E.g., compared with a Model T, modern cars are much easier but much more complex because the car itself understands things like adjusting the ignition timing and safely getting the motor turning, things that a Model T user had to understand if they wanted to avoid getting a broken arm before they got out of the driveway: https://www.fordmodelt.net/how-to-drive-ford-model-t.htm https://www.fordmodelt.net/how-to-drive-ford-model-t.htm
solarkraft 7y ago
It's simple to use.
- umvi 7y ago
  Most of the time, yes, if SQLite supports the filesystem you are using. If the filesystem doesn't have a particular feature SQLite needs, it can be difficult to get working the way you want it to.
  - danso 7y ago
    What scenarios/filesystems lead to these kinds of conflicts?
    - franga2000 7y ago
      Not exactly a filesystem, but it doesn't work on SMB shares, which is an enormous pain in the ass. And I'm not even talking about concurrent access - just one user. I get that SMB file locking is a mess, but making it a hard fail by default was a big mistake IMO as most develoers using the library don't make special cases to allow this.
      - nomel 7y ago
        The documentation is very clear than SQLite over a network isn't a good use case, for reasonably sized data. Item 1 from "Checklist for choosing the right database engine" [1] > 1. Is the data separated from the application by a network? → choose client/server > Relational database engines act as bandwidth-reducing data filters. So it is best to keep the database engine and the data on the same physical device so that the high-bandwidth engine-to-disk link does not have to traverse the network, only the lower-bandwidth application-to-engine link. > But SQLite is built into the application. So if the data is on a separate device from the application, it is required that the higher bandwidth engine-to-disk link be across the network. This works, but it is suboptimal. Hence, it is usually better to select a client/server database engine when the data is on a separate device from the application. 1. https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html
    - umvi 7y ago
      Well the issue I ran into was that I wanted a SQLite db to have one writer and many readers. However, what I was seeing was that queries were failing because the DB was locked at the time of reading. The solution is to switch journaling mode to WAL[1]. However the particular platform I was developing for was an embedded system using the JFFS2 filesystem. JFFS2 doesn't support shared mmap, which is a feature SQLite needs for WAL. So basically, it was big pain - I had to setup a tmpfs mount point where the WAL-enabled DB resided and then periodically sync it to flash. [1] https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html
scottlamb 7y ago
> I mean, reading about how they test it[1] leads me to believe it is not simple. They are unusually thorough in their testing. I see that as a good thing, not a sign it isn't (relatively) simple. In fact, I don't think any other database engine is tested as thoroughly. I can't even imagine how much effort it'd take to do so for Oracle or even PostgreSQL, except that it'd be prohibitive.

gwd 7y ago

I'd say there are a load of reasons, all of which combine together to make it unbeatable: * Simple to embed into you application (no setting up a separate database, &c). * Fantastically backwards compatible * Public domain (so easy to comply with the license) * High quality: Reasonably fast, reasonably efficient, reasonable feature support. The lack of any of these would add significant drag. It's difficult to imagine any other project catching up and displacing it at this point.

bob1029 7y ago
I personally cannot see any near term replacement for what SQLite offers. In my world, SQLite became the way in which I now manipulate a scope of structured data on a single logical disk. I mostly view it as a very reliable and friendly layer on top of basic file IO which also happens to be compatible with virtually every computer on earth. I can copy a SQLite database out of an embedded microcontroller environment and directly open it on my x86_64 workstation, edit some values, and then copy it back down without any fears of compatibility issues.

thrower123 7y ago

I do wonder how much of the time that SQLite is used, that it wouldn't be even simpler to just dump things to an XML file.

lurker458 7y ago
Here are some considerations why: https://danluu.com/file-consistency/ https://danluu.com/file-consistency/
- xolox 7y ago
  Thanks for sharing that link, it's on the most valuable things in this thread for me! (I loved SQLite already and one HN thread more or less isn't going to change that)