It looks good overall. I found one issue, tho.

If you modify a primary key, then the down migrations won't be correct.

Example:
Let's say you have a table user with columns id -- Primary Key, name and the following row:

id: 1, name: "test_name"

Now, you modify this row to be:

id: 10, name: "test_name" <-- PK column was changed

The generated migrations will look more or less like this:

// UP

update table users set id = 10 where id = 1;

// DOWN
update table users set id = 1 where id = 1;

The down migration won't have any effect, because there's no row with id=1 anymore.

The same would go for tables with no PK, where we generate where clause based on all the columns.

The solution would be to determine whether PK was changed and use the proper where clause in down migration.

Leaving some comments for your reference. @Varun-Choudhary

I noticed that you stopped using primary key info to generate where clause.

Let's take a look at some examples and the expected behaviour:

Table with PK

table: user
columns: email (PK), name, age

entries in DB:
ola@ola.com, ola, null

Now, I want to edit my DB entry and mark it as migration. PK can be modifiable, so there are two scenarios (if PK wasn't modifiable, e.g. it was auto-generated, we would have only 1. scenario):

1. I'm editing name, leaving email (PK) as it was:

// rql
{
 type: 'update',
    args: {
      table: {
        name: 'users',
      },
      where: {
        email: 'ola@ola.com',
      },
      $set: {
        name: 'aleksandra',
      },
    },
  }
}

The where clause should ONLY consist of columns that are primary keys. In this case, it's email.
Up and down migrations:

-- up

update table users set name="aleksandra" where email="ola@ola.com";

-- down

update table users set name="ola" where email="ola@ola.com";

2. I'm also editing PK:

// rql
{
 type: 'update',
    args: {
      table: {
        name: 'users',
      },
      where: {
        email: 'ola@ola.com',
      },
      $set: {
        name: 'aleksandra',
        email: 'aleksandra@aleksandra.com',
      },
    },
  }
}

Up and down migrations should look as follow:

-- up

update table users set name="aleksandra", email="aleksandra@aleksandra.com" where email="ola@ola.com";  -- USING ORIGINAL PK

-- down

update table users set name="ola", email="ola@ola.com" where email="aleksandra@aleksandra.com"; -- USING NEW PK, BECAUSE WE WANT TO REVERT 

Tables without PK

The current behaviour should be applied — where clause should consist of all columns.