I really love these pure store tools men. The things you can do with them in insane. The bad part is most application developers dont know about them.

Yes! RocksDB is incredibly powerful with proper setup and key schemas.

Following on that project I might build other things like a stream/queue broker, which will probably fit decently with RocksDB as well

Databases are mostly a solved problem, but building chat features still means re-implementing the same things every time: threading, pagination, edits, soft deletes, encryption etc.

I’m working on a database where those chat-specific primitives (and the operational plumbing around them) are built in.

Think of it like the cloud chat API providers, but reduced to just the storage layer.

It’s not for every use case, but if you’re building anything chat-like AI or trad chat it might save you from rebuilding the same infrastructure again.

Would love feedback. I’m also taking a waitlist for anyone interested in using it.

I know nothing about data centre stuff but this is pretty nice. - especially to even learn about it.

I feel there is more to this you might be working on - so if yes.

Your small internet friend says continue.

All the best.

Hi - dont know how to answer you directly - but yes the store has an index already, at a timed sequence for example. And a key called thread:thread_meta.

This statement is in no way saying you dont need an index, its simply saying, this is the variety of ways people might end up choosing.

Which is just 1 example of the type of work - a thread model & compatible store can fix and fix more efficiently.

In no way fancy too - this is just redis with a disc and some steps imo.

I can access it - and dont see any resource outages etc.

Hmm - you can access it directly or its not showing when you visit?

Thanks & upscaled the vps a level up just in case.

It is now back up.

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.

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.

It dosent work 100% of the time & can get you gotchas that you need to fix - From my experience with it.

Use ably.com - it's not fun and reliable to use websockets yourself. Cloudflare offers a similar service.

Or you can go for a full service like getstream.io or cometchat.com

The latter, I have found to require a lot upfront and have their own ways to do things. It's not bad if you are okay with it.

They cost somewhat a lot but provide up to par service.

Good stuff - always wanted to write bash but not really write bash or learn it deeply. It's amazing world seeing these tools come out.

Just built a CLI a couple days ago with golang and it was an incredible experience where these things have come.

Things - acute product dev tools. Tools to create peculiar or not soo common tools.