[Yandex Cloud documentation](../../index.md) > [Yandex Data Transfer](../index.md) > [Step-by-step guides](index.md) > Working with databases during transfer

# Working with databases during transfer

When working with data transfers, you must take into account the specific features of databases.
While the transfer with replication is running (_**Replication**_ and _**Snapshot and increment**_ [transfer types](../concepts/index.md#transfer-type)), the data on the source and target may differ, so during this time, errors may occur when reading data from the target database. After [deactivating](transfer.md#deactivate) the transfer, all data on the source and target will be the same (eventual consistency).

## MySQL {#mysql}

* For transfers in the **Copying** status, any changes to the data schema (`ALTER`) on the source or target will interrupt the transfer.

* For transfers in the **Replicating** status, you can change the data schema on the source. All `ALTER` operations recorded in the binary log (binlog) on the source will be automatically applied to the target. This process takes some time, so the transfer may slow down.

## PostgreSQL {#postgresql}

{% note tip %}

The PostgreSQL replication protocol does not support transferring schema changes. Avoid changing the data schema in the source and target databases during the transfer. If this cannot be avoided, perform explicit checks on the target.

{% endnote %}

For _**Snapshot**_ and _**Snapshot and increment**_ transfers:

* In the **Copying** status, changes to the data schema on the source and target are not allowed.
* In the **Replicating** status, any changes to the data schema on the source should be manually applied to the target, otherwise the transfer will not be able to continue.

   For example, suppose we added a new column to the `test_table` table on the source:

   ```sql
   ALTER TABLE test_table ADD COLUMN val2 TEXT;
   ```

   If writing to this table continues, the transfer will not be able to insert data on the target. For replication to continue, run a similar query to change the data schema on the target:

   ```sql
   ALTER TABLE test_table ADD COLUMN val2 TEXT;
   ```

   After that, the transfer can continue.

## MongoDB {#mongodb}

* For transfers with the **Copying** status, you cannot perform any actions reducing the origin's _operation log_ (oplog) time window. You should not add, delete, or reconfigure shards in any way during copying or perform any other actions resulting in a shorter operation log time window.

* In **Replicating** transfers, you may encounter an issue with key duplication when a sharded MongoDB cluster with a sharding index other than `_id` is the target. While a transfer is underway, we caution against creating clusters with sharding indexes other than `_id` on the target.