The article says
"[being implemented in motorcycles] would also create a host of reliability issues, considering motorcycles endure far more than cars do.
On motorcycles, brake-by-wire would require a lot of redundancy and failsafes to make sure that the smallest malfunction wouldn't endanger the rider."
I don't see why that isn't the case for cars.
Why don't cars require redundancy and failsafes?
To be fair, I'd love a plugin/framework/microservice you could simply on top of Postgres for having CouchDB's offline synchronization capabilites.
Like the syncing capabilites for mobile and other "sometimes offline" devices are fire.
But in my stack, everything else is already running in a Postgres already, and that's the source of truth.
At one point I started to explore what you would need to adapt any MongoDB compatible DB to work with CouchDB-style synchronization. The biggest problem is you need a consistent Changes view of the database and that's optional from MongoDB-provider to MongoDB-provider. Had I continued on that project it probably would have wound up Azure CosmosDB-specific, specific enough that it didn't feel particularly good for ROI, and was starting to feel like a "back to the drawing board/time to leave CouchDB" situation. It's interesting to wonder if the CosmosDB/DocumentDB pieces that Microsoft is open sourcing (as mentioned in the article here) would eventually include a Postgres extension for their Changes view? Had that been done when I was evaluating options in that past project, it might have lent more weight to that ROI decision that it would also support open source Postgres databases with these open source Document DB extensions.
I don't see why that isn't the case for cars. Why don't cars require redundancy and failsafes?