The difference being that the database is usually _in addition_ to a relay. It's like a relay backend. A backend to a backend, basically.

And it's another thing that could break. Adds complexity and maintenance costs, not necessarily storage costs. Also raises the cost of onboarding new maintainers, as it's one more thing they have to learn.

I do a lot of pipelining and chaining, and each little thing included drives up the chance of the whole thing breaking.

Reply to this note

Please Login to reply.

Discussion

Yes I think that's why so few have done it yet. Convenience. But the power will increase 100x because cloud systems are 1000x bigger than relays systems and always will be. The main problem with the default database is that there's limited indexes which leads to centralzation of development, as developers have to ask permission to get a kind, or an index. Every other DB pushes that decision making to the developer.

Yeah, but that's why database integration and migration is a nightmare. Using a communications protocol to structure the core intra-db communication, so, that it can transit over common relays, is next-gen document db. Especially, as the protocol increasingly branches into subdomains, with their own specialty events.

Turns the Internet into a real Internet of Databases, rather than mere web pages.

So few have done it because most of the devs aren't DBMs. 😅

It's only really getting traction, now, because the relay devs and data analysts have started working on it, and their npubs are finally large enough for everyone interested to see what they're saying.

Team Backend has entered the chat.