- 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.
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.
> 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.
> 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.
> 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.
> 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.
> This is a reasonable idea, but it seems like you want to focus on embedded use cases, not client/server,
Not sure how I was unclear (sorry if I was), my take was basically "I want PostgreSQL[-like] engine that can work in embedded and client-server mode depending on project" really. I want more choice than we have right now, that is my wish.
> and this sounds like something that would be best implemented as a third solution entirely, not a fork of either SQLite or Postgres
I don't see why. Technically there are hurdles, sure, but there always are anyway -- I believe in the case of both SQLite and PostgreSQL it's either lack of resources or lack of motivation to go outside their niche. Whatever the case I am not judging them, it's their project and I am just a rando who wants to work less on their storage / validation layer.
But yeah, I don't see why must we get a 3rd player necessarily. You might still turn out to be correct, mind you, I am just saying that it's not necessarily the case that this DB engine (that will have both embedded and client-server modes) must be a separate project.
I love SQLite but I always end up having to write a lot of validation and at one point you do ask yourself whether your energy should not go somewhere else.
- 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.