Y-Websocket does not explicity support subdocs, but rather treats them exactly the same as any other YDoc. They need their own provider. For example, in the code on this page, at the bottom you can see an event is fired when a subdoc is loaded. The example code then wires up a new provider for the subdocument.
As it stands now, you would need a websocket provider and separate websocket connection for each subdocument. That being said, it’s not terribly hard to add multiplexing support to sync many subdocs over a single websocket connection. One way to do this is to extend the y-websocket server message protocol, found here, to include a message type for subdocuments. In my case, I just added a new message type called “subdocumentSync” that included the id of the target subdocument. Then I use the same websocket connection to perform the sync operation on that subdocument. You would also need to extend WebsocketProvider to understand this new message type, as well.
In regards to the numerous indexeddb entries, it’s true that every indexeddb provider you create will result in a separate database. I’m not sure if there’s a limit on how many dbs a browser can have; I’ve been curious about this as well. You could probably modify y-indexeddb to use individual tables for subdocuments, but if the allowed amount of indexeddbs is functionally unlimited, it would probably be wasted effort. I’d need to do some research on this.
Also make sure you absolutely need subdocs! YJS is super duper simple when you aren’t using subdocs. Subdocs are incredibly useful, but add some complexity to your application design. That being said, if you need them, they are awesome 