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!

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!

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?

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.

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.

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.

> For better or worse, the web has always been driven by specifications, rather than implementations.

Surely you're joking ? Having things done by specifications first has been extremly rare, pretty much everything rather followed the "make the specification after the fact to be whatever X browser has done and is used". Protocols, markup, css, javascript, the whole thing was done by implementation.

There's a difference between "standardizing an implementation so everyone can use it" and "just use this standard implementation".

But IndexedDB has been struggling very hard from day 1 to be as fast and performant as WebSQL. You can do the benchmark yourself [1]. Try inserting 10000 records. WebSQL is by orders of magnitude faster than IndexedDB.

The people who rejected WebSQL proposal had a lack of decisiveness and technically-focused vision. They also interpreted everything very politically.

[1] http://scaljeri.github.io/indexeddb-vs-websql/v2.0.0/

> 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.

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.

Internet Explorer would like to have a word with you. It was clearly an “implementation over specification” effort.

But the policy is to only accept a standard where there is at least two independent implementations. This was realistically never going to happen with the SQLite.