3 ms·

> What seems contradictory, not sure I understand? In-process embedding implies making the DB engine part of the program itself, within a single runtime instan

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

pdimitar 2y ago
> 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.

by Gormo 2y ago

pdimitar 2y ago

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