Store deleted rows via deleted_at or separate table?

Question

Database

Good afternoon!

Question for highload developers, but not a fact :)

There is a multi-user application where the state of the deleted data will need to be synchronized with end users.

the need to store remote data arises for the following reason:
the user stores data in indexdb, which is then synchronized with the server.
When synchronizing, you need to get from the tables data on updated_at create_at deleted_at that were after the last synchronization.

The question is what are the options for storing deleted data.
I see two options.

1. Have a deleted_at column where the deletion date will be stored. In that case at each request in , or join it will be necessary to specify. where deleted_at is NULL .
Of course, the engine will allow all this to be automated.
But what about performance when there are millions of rows in tables and various other "where"
It will be necessary to constantly indicate deleted_at in indexes or how to do it so that there would be no problems with the speed of data retrieval? What are the practices.
Partitioning?

2. Have a database mirror to which deleted rows will be moved.
Pluses, requests base are facilitated.
Minuses? well unless to synchronize structure of tables.

3. It is possible to create the table in which pairs table_name id deleted_at would be stored. which could be used for synchronization.

I would be very grateful for any information in this direction, or a resource where you can read about architecture!

Answer 1

Is it the legs growing out of the dbase where the deletion was not a deletion per se?
What is the disadvantage of pure delete using DBMS tools?