I think the EU mandate forces them to do both, so that devices with AWDL are not advantaged over non-Apple devices with Wi-Fi Aware, so my read is that mandate will mean Apple devices will do both modes until they can transition AWDL off entirely.
1. Yes Ditto uses query-based sync. Candidly, the flexible sync in Atlas has roots back to when I was VP of Product at Realm. It was a must for me, but I think got abandoned for performance issues then brought back. Ditto was built always to support flexible/query sync. We recently have added our own more advanced query engine - DQL (SQLish) and it will enable JOINs and other advanced queries while still being schemaless JSON collections. In this regard Ditto is a better compliment to Mongo than Realm is from data model perspective.
2. Yes this partner-first approach is huge opportunity for us. Given Realm had to sell, we were very focused on building a sustainable business. This meant though more focus on enterprise and specific use-cases than going wide to all developers (you can see how well that worked with Firebase, Parse, and many other developer products when you have VC backing). This means we have a solid foundation technically (large-scale deployments in mission critical systems) to now handle wider awareness. Mongo will really help us bring the awareness of Ditto.
3. Right now candidly our permission system is nascent compared to Atlas - a webhook fires from Ditto to allow you to integrate into external identity systems and apply permissions. The focus with enterprise meant we targeted use-cases that didn't have too much dynamism in their permissions and data models, so you will find our system naive comparatively. This is a top priority where we will be adding built-in dynamic permission functionality that is similar to Device Sync later this year. You can read more on our system here: https://docs.ditto.live/auth-and-authorization/data-authoriz...
Yeah the client has to serialize/deserialize - think of the DB as a mini Mongo where you insert JSON into collections as the mental model. Reason for this is that in our experience, sync is easier when the system is schema-less because the nature of the system ties folks across teams, so this means the schema tends to live above each individual client (iOS, Android, backend, etc and in larger orgs those are each separate teams). Furthermore, advances such as Codable in Swift and other patterns means client devs are fairly used to handling this with JSON/REST patterns anyway.
More similar is that Ditto uses a query-based sync approach - this was an area I am particularly passionate about and helped push at Realm. The challenge with this vs. strict channels is then scalability of the backend system - but we have solved these scalability challenges in several ways.
Most prominently, internally Ditto works different than at least my understanding of how Realm Sync worked originally (it might have evolved more under Mongo). We use CRDTs to handle the conflict resolution, so any JSON inserted into Ditto, ends up being a nested CRDT structure on disk. This enables the same predictive conflict resolution, but its a crucial trade off compared to other approaches.
First, CRDTs enable P2P sync where no server is needed to mediate the system. This opens up use-cases that Ditto powers where mobile devices sync over Bluetooth and P2P WiFi even without a device accessing the internet. Furthermore, it also opens up more scalability on the backend because the server nodes themselves can communicate P2P.
At a more fundamental level this is a trade off of using extra metadata (CRDTs include more context like version vectors and such to know how to merge with each other) compared to Realm's original approach of Operational Transformation which is an algorithmic approach. We felt that the metadata approach was holistically better because of the access to new use-cases and scalability meanwhile there are clever ways to make the metadata cost not a real-world issue (i.e. compression in various ways). Conversely, the algorithmic approach is limited to a client server architecture and has computational scalability issues.
All in all, we are very sympathetic to transition costs, but are confident folks will find Ditto can meet the same and more capabilities in Device Sync. Our current challenge is going to be introducing a pricing scheme to support the broader set of Mongo users. To date, we have been very focused on larger enterprise deployments (gotta ensure the bills are paid!) so we will be creative to ensure anyone transitioning is not affected by pricing if they like us!
Adam (CEO of Ditto) here, Mongo is transitioning to a partner-first strategy for mobile and edge applications. We are working closely with Mongo to create a cohesive product experience between Ditto and Mongo Atlas. High-level that is a supported bidirectional connector between Atlas and Ditto's Edge Sync platform.
Furthermore, we are working with customers of Atlas Device Sync to help and support them in the transition. There are aspects of Ditto different than Realm - most prominent is that we are schema-less. This will mean some client-side code transition, but longer-term a tighter alignment with Mongo Atlas. We are excited as well to introduce more to Ditto's unique capability of P2P device sync.
Note, I previously worked at Realm before the Mongo acquisition and even before joining the team I was an avid fan of the database. I hope it continues life via the community!
Adam (CEO of Ditto) here, happy to answer any questions! Really excited about this partnership and the potential to combine our unique P2P capability (powered by CRDTs) with Mongo Atlas.
Our belief is that edge devices are super computers that shouldn't be treated as dumb clients. These devices can store data, perform advanced computation, and connect to each other directly - which is what Ditto enables.
This doesn't mean the cloud is going anywhere, centralized systems still play a major role, especially in large scale AI workloads (where Mongo's vector search means you don't need other tools). However, the cloud is not guaranteed from connectivity failures to backends issues (like CrowdStrike outages).
Ditto + Mongo means you can build resilient applications that leverage the best of the edge and cloud!
Adam (cofounder) - great question! Yes, this situation is very common for our use-cases. Ditto supports the concept of `eviction` [1]. For example, imagine a restaurant that wants to store all of today's orders in their devices, but then evict the data when they close out at end of day (and data is synced into Cloud backend). Eviction is a core concept because we consider devices using Ditto's SDK a "Small peer" that should only have the data it wants - queries define which data is synced and you can always evict anything unneeded. Conversely, the server version of Ditto is a "Big Peer" that is a cluster designed for scalability and fault tolerance, so it wants to capture everything. Another way to put it is selfish vs. greedy replication.
To help users with eviction, we are adding support for dynamic queries, for example, using "now" for a date in the query to aid in creating TTL logic. In addition, to built-in TTL as well.
Satellite comms are definitely a great fit for another reason, since Ditto's replication is "delta-based" it will only sync differences. Our protocol is designed to overlay on top of custom arbitrary links, including unreliable ones. Not familiar with CCSDS, but we have explored Link16, and even built-in we replicate over BLE GATT.
Hope that helps and perhaps we can get Ditto into space!
Adam (Ditto cofounder) - thanks for the feedback! I can see how this can create the wrong impression and will follow up with our counsel to improve the language.
To be clear, we are not in the business of selling personal information. We are in the "picks and shovels" business - building great tools for other developers to use. Both myself and cofounder Max are app developers by background and we got into infrastructure software by wanting to simplify app development for ourselves and others. P2P is highly motivating because it enables use-cases that have greater data control and privacy - both of which are deeply important to us.
Adam (cofounder) - Yes we evaluate applicants holistically. Rust is still newish and we have a mix of team members that came with lots of experience to just some familiarity. I have a strong philosophy that Ditto's success starts with a great team (build the inputs to get outputs concept), so aptitude is a major factor - please apply if interested!
Adam (Ditto cofounder) - Ditto can be used either as the primary datastore in the client app (we call these "Small Peers"), or alongside others local DBs (existing apps adopting Ditto tend to pick off key P2P features and run Ditto with others like Couchbase, SQLite, or Core Data - and we have built connectors to help with this). With regards to the backend, our server product, or "Big Peer" provides webhooks or a Kafka topic of all changes to pipe them into other systems, so it similarly can be a primary datastore or middleware.
All-in-all, the design of Ditto is to be flexible so users can add Ditto to their architecture as easy as possible.
Shameless plug but would love for you to try out Ditto[1]! CRDT-based replicated database that works peer-to-peer including automatically with WiFi and Bluetooth.
Incredible product, journey, and financial success. Nevertheless, I bet this was not an easy decision. Losing independence even with all the other great aspects isn't ideal. Just a guess, but I bet the prospect of doing layoffs compared to selling played a role. Gitlab/Monday are public comps and currently worth less than Figma's last valuation.
Similarly, a gov registration fee website simply disabled the “next” button at UI layer because I was late from the deadline. Easy bypass and paid fee, never heard anything else.
Great summary. CRDTs are a better fit for generalized data. Having previously worked on an OT system, the central server stickiness and merge complexity simply did not scale. There are trade-offs with CRDTs, especially metadata, but as the post mentions compression techniques are far more solvable in real-world scenarios than a fundamental performance bottleneck at the core.