Limitations
These are current limitations of dsync— take note that these areas may require manual intervention or special consideration during your migration process.
Last updated
These are current limitations of dsync— take note that these areas may require manual intervention or special consideration during your migration process.
Last updated
Currently, dsync does not replicate Data Definition Language (DDL) statements or indexes from the source to the destination. This means that any database schema changes or index configurations must be handled separately to ensure they are correctly applied to the destination.
Dsync does not manage conflicts on the destination system. If documents with the same _id already exist on the destination, they will be overwritten by the incoming data from the source. As a result, users need to take care when migrating data to avoid unintended overwrites.
Current data partitioning for Cosmos DB only works for collections with _id values of the ObjectId type. It works best when the values are evenly distributed through the lifetime of the collection, which is true for most applications.
vCore Cosmos version only supported as a destination as it doesn't expose the ChangeStream API yet.
We cap the number of namespaces to 8 when Cosmos DB is used as a source. This is due to a performance impact that we observed with more than 10-15 parallel ChangeStreams. You can use to specify which namespaces to sync.
Since Cosmos DB change stream events don't expose any sequence number, we rely on an approximate client-generated sequencing mechanism. Due to its approximate nature, the reported replication lag might be greater than the actual value.