4 ms·

The optimistic concurrency is a feature of SQLite, not their sqld server. And I think there are other approaches to replication that still retain the embedded

• aerio 3y ago
  >why wouldn't you just use postgres Because postgres is not single file?
  • ChoHag 3y ago
    [dead]
  • runeks 3y ago
    Why do you want something that writes to a single file?
    • onetoo 3y ago
      The mental model of "a single DB file" is a easier to grog than a large and seemingly opaque DB server. Most (all?) of the well-known RDBMS are designed to host the data needs of multiple separate applications, which makes configuration look a lot more complicated when all you want is n=1.
      • mbreese 3y ago
        But then why do you need to write to the DB remotely? It seems like the inflection point moving from "single-local-application" to "writing-to-remote-db" would be an appropriate point to switch from a single file DB to a larger RDBMS. I can think of a few scenarios where it could make sense, like a shared small DB on a LAN that doesn't need a full fledged "server", but a primary/secondary relationship makes sense. But those are pretty few... and n>1. Obviously someone wrote this because they felt a need for it, but I'm struggling to see the use-case. Maybe it's good for CI/or unit testing?
        • pastage 3y ago
          The use case mentioned for http is: you have edge services that need to be able to query a db and http might be the only open way to communicate. Exactly why you run on the edge or use sqlite is actually off topic. I mean I run User Mode Linux in production because it was just easier than the alternative when we first developed it.
        • upon_drumhead 3y ago
          I self host a lot of stuff at home. I don't need a large RDBMS. A lot of software is written for Postgres and I don't bother running it as I don't want to manage it. I'm really interested in this if I can start using those apps now, without spinning up postgresql.
      • ElectricalUnion 3y ago
        > easier to grog than a large and seemingly opaque DB server. Not really, with this solution now you need to manage a non-replicated, non-high-availability mock of Postgres where every user is 'postgres', dealing with the usual remote RPC call issues and latency. If you need to manage a RDBMS anyways, you probably can manage Postgres; if you can't manage Postgres then it's unlikely that you will be able to manage this solution as well.
    • maitredusoi 3y ago
      [dead]
• pastage 3y ago
  Obviously because you already run sqlite and need to access it remotely for some reason. You might want to standardize how applications like Datasette works and use a known working library for the postgres wire protocol.