Return to Answer

What's the ORM you're using?

You could use advisory locking to avoid the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting 
    --a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

Honestly, relying on an order by clause to avoid deadlocks seems a bit fragile solution.

More info about explicit locking functions here.

What's the ORM you're using?

You could use advisory locking to mitigate the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting 
    --a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

Honestly, IMHO relying on an order by clause to avoid deadlocks seems a bit fragile solution.

More info about advisory locking functions here.

What's the ORM you're using?

You could use explicit locking to avoid the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting 
    --a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

Honestly, relying on an order by clause to avoid deadlocks seems a bit fragile solution.

More info about explicit locking functions here.

What's the ORM you're using?

You could use advisory locking to avoid the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting 
    --a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

Honestly, relying on an order by clause to avoid deadlocks seems a bit fragile solution.

More info about explicit locking functions here.

What's the ORM you're using?

You could use explicit locking to avoid the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

More info about explicit locking functions here.

What's the ORM you're using?

You could use explicit locking to avoid the deadlocks:

UPDATE 
    "records" 
SET 
    "last_data_at" = '2019-09-11 20:21:58.496318' 
WHERE 
    "records"."id" IN ($1, $2)
    --This function will return TRUE if getting 
    --a lock is possible for current transaction
    AND pg_try_advisory_xact_lock("records"."id")

Honestly, relying on an order by clause to avoid deadlocks seems a bit fragile solution.

More info about explicit locking functions here.