> 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

> 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. Time will tell, I suppose.