This comes across as a 100% vibe-coded system that could really just be a table or two in a standard SQL database with some care taken with indexing and partitioning (when you reach that point).
What am I missing? What would compel someone to abandon a battle tested system like PSQL for a critical storage engine for this?
You can do an append-only table like this in any SQL database. You can use composite keys to achieve the query+natural sorting abilities over a single field. The effort to replicate this feature in any other environment is so minimal that it the 'vendor lock-in' makes this a non-starter in my eyes.
hasante•1h ago
Hi - its not - more about 20% - for tests and non critical things.
Focusing on your abandonment part etc etc:
- Its not really trying to achieve that, this is simply a more efficient model, with a good storage coupling (for chat).
- What is being achieved here is a cohesive solution for chat specific workloads and optimising for it.
One of the benefits is speed (throughput, latency) - and very cheap calls.
More so - under sql, and for developers who have different demands and mostly changing demands - the effort is quite complicated situation (I speak from my own experience)
The focus here is a simple downmost layer - that allow all the varieties of top layers & requirements to be achieved easily.
In my blog post - i share a variety of these.
Also product is not ready - but thought i share this idea - as i think it can be of benefit to most devs who are starting out with a product.
You technically dont even need progressdb to achieve it - You can do it with a backend based pebble or rocksdb database.
hasante•1h ago
The database is completely opensource and is technically backed by Pebble golang - which is opensource.
There are no changes to the underlying core, i simply make it easy to use operationally, along with other chat centric demands in the AI age.
e.g Backups, Retention, Scaling it up etc.
So there is no "Vendor lock-in" - and i plan to opensource everything.
I dont even feel i own the idea - its pretty out there, am just bringing eyes towards it.
whalesalad•2h ago
What am I missing? What would compel someone to abandon a battle tested system like PSQL for a critical storage engine for this?
You can do an append-only table like this in any SQL database. You can use composite keys to achieve the query+natural sorting abilities over a single field. The effort to replicate this feature in any other environment is so minimal that it the 'vendor lock-in' makes this a non-starter in my eyes.
hasante•1h ago
Focusing on your abandonment part etc etc:
- Its not really trying to achieve that, this is simply a more efficient model, with a good storage coupling (for chat).
- What is being achieved here is a cohesive solution for chat specific workloads and optimising for it.
One of the benefits is speed (throughput, latency) - and very cheap calls.
More so - under sql, and for developers who have different demands and mostly changing demands - the effort is quite complicated situation (I speak from my own experience)
The focus here is a simple downmost layer - that allow all the varieties of top layers & requirements to be achieved easily.
In my blog post - i share a variety of these.
Also product is not ready - but thought i share this idea - as i think it can be of benefit to most devs who are starting out with a product.
You technically dont even need progressdb to achieve it - You can do it with a backend based pebble or rocksdb database.
hasante•1h ago
There are no changes to the underlying core, i simply make it easy to use operationally, along with other chat centric demands in the AI age.
e.g Backups, Retention, Scaling it up etc.
So there is no "Vendor lock-in" - and i plan to opensource everything.
I dont even feel i own the idea - its pretty out there, am just bringing eyes towards it.