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