Uber for one as documented here https://www.uber.com/us/en/blog/schemaless-part-one-mysql-da...
There are many more and most may not be documented online.
Our usecase is offline first mobile ERP (roll-out hopefully soon) with online-sync capabilities doing invoice/coupon processing, etc. in a network of regional shops - with a focus on minimizing latency and aggressive reduction of costs at scale.
Once we measured the reduction in latency due to parallel fanout (over index shards - not just data shards) for range scan, there is no going back ever again.
When you need the same database to be running on mobiles and servers alike, you need embedded database for mobile and standalone executable for server.
> they will perform better than the ones built with coordination with the storage engine and everything else?
No amount of coordination with the storage engine can override the physics of lock contention in distributed systems.
> This seems a very unusual set of circumstances so I'm very curious on the use case.
Not with my background. Its the norm :)
> When you need the same database to be running on mobiles and servers alike, you need embedded database for mobile and standalone executable for server.
Most of the people I’ve run into just want some sort of replication system that’s a bit richer than MQTT et al.
> No amount of coordination with the storage engine can override the physics of lock contention in distributed systems.
Carrying on from the previous point. Distributed querying may still just be a workaround rather than something anyone actualy wants to do as a first option.
That’s cool either way Enjoy
That is not the case. Even on a single machine with multiple shards (think hundreds or even thousands of kv engine say LMDB envs), a distributed query parallelizes efficiently. Additionally it can also saturate the SSD/NVMe with multiple write transactions concurrently.
It definitely is the first option and not a workaround. Even replication benefits from this write saturation and reduced latency and parallelism. Naturally, multiple writes involving the same logical unit of work can go through a durable execution framework (think ordered-log/kafka) as one insert and the client dismissed only for the consumer later attempting multiple idempotent writes (logical work with retry on failure) - achieving maximum SSD saturation. The client is later informed of the status.
> Most of the big offline use cases I’ve seen are aerospace/drones or logistics or robotics ...
Our previous ERP (built almost over a decade) for a large enterprise client, required disbursing customers as the absolute paramount priority regardless of internet availability - which is where offline first became the only choice. They wanted data to seamlessly move across thousands of offline systems - which is where we wrestled with replication/conflict resolution, etc. Our new Slyp and SlypBusiness is a reincarnation/re-imagining of this old ERP with added goodies but as mobile first applications.
There is only up to a point where we tolerate other databases, and beyond which the conventional wisdom starts to be a net negative and we realized we are better off building one for ourselves.