Y-websocket server vs ydb for long-term persistent store of documents


We’ve been building an editing experience on top of yjs and y-websocket running as server from the bib directory.

Specifically - this is currently being used a collaboration cache, and is something that can re restarted, migrated etc, without worrying about the data, as that is being stored elsewhere, by syncing contents from individual rooms.

I came across https://github.com/yjs/ydb, which actually seems to be a database built with yjs, but has not seen activity in some time. It is also lacking documentations.

Provided I’m looking for a “single node” data store of yjs documents that can be the final store for end documents, is ydb a good choice? Specifically,

  • is there a backing store option (can I plugin in postgres or mysql or other managed db node)
  • I don’t care about horizontal scaling - simple vertical scaling can fit my usecase.
  • is the internal data schema of yjs frozen? so that this data will be accessible for the foreseaable future of yjs?

Right now I’m investing in dumping room data as json and storing it, but I can skip that if ydb is a reasonable option for it.

Is there any help I can offer on above?

Hi @anilg,

If you look in this discussion board you will find numerous persistence layers that work with Yjs. You can definitely base your own persistence approach based one of these.

There is still more work to be done. ydb was a project that was supposed to support horizontal and vertical scaling. I implemented a custom protocol that is able to sync several rooms at once. I learned my lessons and paused the project because I found no sponsors for this project.

A go implementation of Yjs’s sync protocol has a lot of merit. But by now ydb is completely deprecated and I suggest to simply start a new project if you want to.

I do plan to provide a native implementation of Yjs that will allow you to efficiently sync with little memory overhead. You can read more about my plans in How is y-leveldb coming along?

The sync protocol v1 is now frozen. There is also a v2 implementation that uses a compression approach to reduce the document size further. v2 is still experimental. Both encoding approaches will be supported in the future.

You should also have a look at y-leveldb and y-mongodb.