I want to design a PostgreSQL database for my product which needs to handle ordered many to many relation. There is two solution for that:
My data model is like this:
Table 1(Exercise):
id
name
Table 2(Workout):
every user can create custom workout(list of exercises with defined order). my problem is saving the order of relations in database, because default relation not preserve order.
As has been said in the comments, "best practice" supposes that there is exactly one best way to do things, and that is not the case. In pretty much all software design solutions, you have to trade things, in messy, unpredictable ways, which are nearly always context-dependent.
If I understand your question, your problem domain has the concept of a "user" who creates zero or more work-outs, and each work-out has one or more exercises, and the sequence in which that exercise occurs is an important attribute of the relationship between workout and exercise.
The normal way to store attributes of a many-to-many relationship is as additional columns on the joining table.
The normalized way of storing this would be something like:
user
-----
user_id
name
...
Workout
-----
workout_id
name
....
Exercise
------
exercise_id
name
....
workout_exercise
----------
workout_id
exercise_id
sequence -- this is how you capture the sequence of exercises within a workout
... -- there may be other attributes, e.g. number of repetitions, minimum duration, recommended rest period
user_workout
--------
user_id
workout_id
.... -- there may be other attributes, e.g. "active", "start date", "rating"
In terms of trade-offs, I'd expect this to scale to hundreds of millions of rows on commodity hardware without significant challenges. The queries can get moderately complex - you'll be joining 4 tables - but that's what databases are designed for. The data model describes (what I understand to be) the problem domain using separate entities etc.