5 ms·

I wish SQLite would officially fork itself and: - So make breaking changes as needed. (it was first released in 2000 and has fantastic backwards compatibility,

I wish SQLite would officially fork itself and: - So make breaking changes as needed. (it was first released in 2000 and has fantastic backwards compatibility, but hardware & OS have radically changes over the last 24 years - as well as use cases). - put more focus on client/server use cases - make things more 'strict' (types, checks, etc) Note: I say this with tremendous love for SQLite. There's just so many attempts for companies & projects to morph SQLite what it's not designed for, that you might as well embarrass these use cases and make an official fork to support them.

richie_adler 2y ago
It will never happen. Please, move on.
Gormo 2y ago
I guess I don't really understand the point of expecting distinct solutions to all converge toward the same general case. All of the criteria on your list are already fulfilled by Postgres, MySQL, etc. -- why dilute the optimality of SQLite for its specialized use cases just to target other use cases that are already served superbly with other tools? This is like arguing how great bicycles would be if they had four wheels, enclosed cabins, and gasoline engines.
- pdimitar 2y ago
  > All of the criteria on your list are already fulfilled by Postgres, MySQL, etc. They are not, they introduce management of another node / VM / pod which I'll boldly say that likely at least 80% of all projects everywhere do not need. I'd kick a puppy if that means we can get in-process / embedded PostgreSQL. > why dilute the optimality of SQLite What does that even mean? Such a strange wording, as if it's a competition or a fight. > This is like arguing how great bicycles would be if they had four wheels, enclosed cabins, and gasoline engines. No, that's akin to arguing that a bicycle would benefit from crash protection if it came with just 2-3kg extra weight.
  - Gormo 2y ago
    > I'd kick a puppy if that means we can get in-process / embedded PostgreSQL. Can you explain your thinking re a solution being both in-process/embedded and focusing on client/server use cases? On the surface, these seem contradictory to me. > What does that even mean? Such a strange wording, as if it's a competition or a fight. I don't know about a "competition or a fight" but forking a project to target contradictory use cases definitely involves trade-offs.
    - pdimitar 2y ago
      > Can you explain your thinking re a solution being both in-process/embedded and focusing on client/server use cases? On the surface, these seem contradictory to me. What seems contradictory, not sure I understand? In my consulting and contracting practice I have only ever had 3 projects that actually needed a big dedicated database. Everything else would have done just fine with an in-OS-process model like SQLite. But SQLite is too lax with data typing and I am not keen on 40% of the invoice for my customers to be "+300% extra data validation code because SQLite devs used and loved TCL". Sorry for the snark, but TCL influencing SQLite is a historical reality, if my memory hasn't betrayed me that is. I'd love it if we had the same DB engine have an embedded and client-server variants. You start off with the embedded and if the project grows then you simply modify its config and don't have to change one line of code in your project (though obviously your platform team has to then provision it but that's a given). Today this is sadly a fantasy and does not exist. I want it to exist. And why PostgreSQL? Well, I like data strictness, and PG has a lot of desirable features like DDL transactions and enum types.
      - Gormo 2y ago
        > What seems contradictory, not sure I understand? In-process embedding implies making the DB engine part of the program itself, within a single runtime instance, in the same way as you'd import any other library. Client/server architecture is a situation in which one program is communicating with another one, running somewhere else, over some sort of messaging channel. On the surface, these seem to be mutually exclusive usage models. > I'd love it if we had the same DB engine have an embedded and client-server variants. It sounds like you want something that uses similar syntax and defaults as Postgre, but is used in an embedded fashion, a la SQLite. This is a reasonable idea, but it seems like you want to focus on embedded use cases, not client/server, and this sounds like something that would be best implemented as a third solution entirely, not a fork of either SQLite or Postgres.

richie_adler 2y ago

It will never happen. Please, move on.

Gormo 2y ago

I guess I don't really understand the point of expecting distinct solutions to all converge toward the same general case. All of the criteria on your list are already fulfilled by Postgres, MySQL, etc. -- why dilute the optimality of SQLite for its specialized use cases just to target other use cases that are already served superbly with other tools? This is like arguing how great bicycles would be if they had four wheels, enclosed cabins, and gasoline engines.

pdimitar 2y ago
> All of the criteria on your list are already fulfilled by Postgres, MySQL, etc. They are not, they introduce management of another node / VM / pod which I'll boldly say that likely at least 80% of all projects everywhere do not need. I'd kick a puppy if that means we can get in-process / embedded PostgreSQL. > why dilute the optimality of SQLite What does that even mean? Such a strange wording, as if it's a competition or a fight. > This is like arguing how great bicycles would be if they had four wheels, enclosed cabins, and gasoline engines. No, that's akin to arguing that a bicycle would benefit from crash protection if it came with just 2-3kg extra weight.
- Gormo 2y ago
  > I'd kick a puppy if that means we can get in-process / embedded PostgreSQL. Can you explain your thinking re a solution being both in-process/embedded and focusing on client/server use cases? On the surface, these seem contradictory to me. > What does that even mean? Such a strange wording, as if it's a competition or a fight. I don't know about a "competition or a fight" but forking a project to target contradictory use cases definitely involves trade-offs.
  - pdimitar 2y ago
    > Can you explain your thinking re a solution being both in-process/embedded and focusing on client/server use cases? On the surface, these seem contradictory to me. What seems contradictory, not sure I understand? In my consulting and contracting practice I have only ever had 3 projects that actually needed a big dedicated database. Everything else would have done just fine with an in-OS-process model like SQLite. But SQLite is too lax with data typing and I am not keen on 40% of the invoice for my customers to be "+300% extra data validation code because SQLite devs used and loved TCL". Sorry for the snark, but TCL influencing SQLite is a historical reality, if my memory hasn't betrayed me that is. I'd love it if we had the same DB engine have an embedded and client-server variants. You start off with the embedded and if the project grows then you simply modify its config and don't have to change one line of code in your project (though obviously your platform team has to then provision it but that's a given). Today this is sadly a fantasy and does not exist. I want it to exist. And why PostgreSQL? Well, I like data strictness, and PG has a lot of desirable features like DDL transactions and enum types.
    - Gormo 2y ago
      > What seems contradictory, not sure I understand? In-process embedding implies making the DB engine part of the program itself, within a single runtime instance, in the same way as you'd import any other library. Client/server architecture is a situation in which one program is communicating with another one, running somewhere else, over some sort of messaging channel. On the surface, these seem to be mutually exclusive usage models. > I'd love it if we had the same DB engine have an embedded and client-server variants. It sounds like you want something that uses similar syntax and defaults as Postgre, but is used in an embedded fashion, a la SQLite. This is a reasonable idea, but it seems like you want to focus on embedded use cases, not client/server, and this sounds like something that would be best implemented as a third solution entirely, not a fork of either SQLite or Postgres.