5 ms·

SQLite is a brilliant lightweight database which is available everywhere. All mobile OSs support it and it's a breeze to run on even embedded Linux. I just wish

SQLite is a brilliant lightweight database which is available everywhere. All mobile OSs support it and it's a breeze to run on even embedded Linux. I just wish web browsers would also support it and make webSQL a standard, it would make programming for the web so much easier.

3fe9a03ccd14ca5 7y ago
Once I discovered SQLite, I never went back. It’s so easy. I’m still shocked when I see docker compose files that spin up entire MySQL dbs when a simple SQLite connector would be so much easier!
- williamdclt 7y ago
  Whether it is in staging, in dev or in tests, use the same DB engine as in prod. It will save your butt sometimes. Also, my docker-compose for a Postgres container is literally: services: db: image: postgres:10 ports: - "5432:5432" "so much easier" seems very hyperbolic. Not denying that SQLite is an amazing piece of software though!
- jopsen 7y ago
  How do you ensure persistence in production? With postgres I just buy a managed setup from heroku, GCP or AWS. Backup is automatic, and there is a follower to takeover if the leader does/crashes. It's easy to backup an sqlite snapshot, but you can't do that after every operation. Curious, how do people solve this?
hasperdi 7y ago
Actually, it was about to become standards. Some browsers implemented it, but then they decided not to go ahead as all browsers will have the same SQLite implementation.
- atishay811 7y ago
  It is weird in the hindsight as with just Webkit(which is most of blink still) and Gecko, there are just two engines left. And when Gecko goes down (which is losing market share), this would seem even more stupid. SQL is a standard. They could have standardized on it rather than an implementation.
  - Carpetsmoker 7y ago
    SQL is a standard, but SQLite doesn't implement "standard SQL", it implements "SQLite SQL". For better or worse, the web has always been driven by specifications, rather than implementations. Properly standardizing all of SQLite in a spec is not trivial, and as much I think SQLite is great software, I don't think that relying on SQLite the library specifically would be a good idea. What if the latest version of SQLite does something that's not in the spec or prohibited by the spec? Either way, there's IndexedDB now, which is supported by almost everything, including IE.
    - Krustopolis 7y ago
      Internet Explorer would like to have a word with you. It was clearly an “implementation over specification” effort.
    - firethief 7y ago
      > For better or worse, the web has always been driven by specifications, rather than implementations. What? The specifications document what browsers already do. Have you seen the HTML5 spec? It's mostly formalization of error-recovery, showing how to interpret previously technically-broken documents in the way modern browsers have converged on. It's not what anyone would design, but there's no one driving.
      - goto11 7y ago
        Sure, but the requirement is there should be at least two independent implementations (as there is for the error recovery in the HTML5 spec). This was never going to happen with SQLite.
    - 7y ago

3fe9a03ccd14ca5 7y ago

Once I discovered SQLite, I never went back. It’s so easy. I’m still shocked when I see docker compose files that spin up entire MySQL dbs when a simple SQLite connector would be so much easier!

williamdclt 7y ago
Whether it is in staging, in dev or in tests, use the same DB engine as in prod. It will save your butt sometimes. Also, my docker-compose for a Postgres container is literally: services: db: image: postgres:10 ports: - "5432:5432" "so much easier" seems very hyperbolic. Not denying that SQLite is an amazing piece of software though!
jopsen 7y ago
How do you ensure persistence in production? With postgres I just buy a managed setup from heroku, GCP or AWS. Backup is automatic, and there is a follower to takeover if the leader does/crashes. It's easy to backup an sqlite snapshot, but you can't do that after every operation. Curious, how do people solve this?

hasperdi 7y ago

Actually, it was about to become standards. Some browsers implemented it, but then they decided not to go ahead as all browsers will have the same SQLite implementation.

atishay811 7y ago
It is weird in the hindsight as with just Webkit(which is most of blink still) and Gecko, there are just two engines left. And when Gecko goes down (which is losing market share), this would seem even more stupid. SQL is a standard. They could have standardized on it rather than an implementation.
- Carpetsmoker 7y ago
  SQL is a standard, but SQLite doesn't implement "standard SQL", it implements "SQLite SQL". For better or worse, the web has always been driven by specifications, rather than implementations. Properly standardizing all of SQLite in a spec is not trivial, and as much I think SQLite is great software, I don't think that relying on SQLite the library specifically would be a good idea. What if the latest version of SQLite does something that's not in the spec or prohibited by the spec? Either way, there's IndexedDB now, which is supported by almost everything, including IE.
  - Krustopolis 7y ago
    Internet Explorer would like to have a word with you. It was clearly an “implementation over specification” effort.
  - firethief 7y ago
    > For better or worse, the web has always been driven by specifications, rather than implementations. What? The specifications document what browsers already do. Have you seen the HTML5 spec? It's mostly formalization of error-recovery, showing how to interpret previously technically-broken documents in the way modern browsers have converged on. It's not what anyone would design, but there's no one driving.
    - goto11 7y ago
      Sure, but the requirement is there should be at least two independent implementations (as there is for the error recovery in the HTML5 spec). This was never going to happen with SQLite.
  - 7y ago