Limitations

These are current limitations of dsync— take note that these areas may require manual intervention or special consideration during your migration process.

General

DDL and Index Replication

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.

Conflicts on 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.

MongoDB

Partitioning

Current data partitioning strategy doesn't support mixing different types of _id values within any collection.

Unique non-_id indexes

Existing non-_id unique indexes on the destination can result in duplicate key errors when the values on the source are being actively changed. In MongoDB v6+ it's possible to temporarily disable the enforcement of uniqueness constraint during the data migration - see MongoDB documentation.

Cosmos DB (MongoDB API)

Partitioning

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 DB

vCore Cosmos version only supported as a destination as it doesn't expose the ChangeStream API yet.

Number of namespaces

By default, we cap the number of namespaces to 8 when Cosmos DB is used as a source. This is due to a potential performance impact that we observed with more than 10-15 parallel ChangeStreams. You can use namespace filtering to specify which namespaces to sync, or you can use the --cosmos-reader-max-namespaces connector parameter to set the limit to a higher number.

Replication lag reporting

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.