What to read about designing a referral user base?

Question

PostgreSQL

Hello everyone.
Now I am designing a database of user network relations.
I have:

• Manufacturer
  
• User - Seller
  
• End user (lazy, doesn't want to sell)
  

Relations are built (already now) according to the principle: whoever brought whom, he sells to him.
There can be many manufacturers (they are geographically separated).
Any user or seller can buy a product from any manufacturer (by prior agreement, it depends on where the buyer is now, well, or on the quality of the product). Theoretically, nesting more than 4 levels now does not occur physically (unprofitable), but you never know where it all wanders on electronic rails.
That is, as a result, a general graph (or network) is obtained, which somehow needs to be pushed into SQL (probably).
I know about graph bases, but so far I haven’t found any advantages for myself to connect a second base to the project, if I can get by with one. In addition, so far, IMHO, the use of a graph base looks either like shooting flies from GRADs, or like introducing an unstable and dangerous entity into the project.
Options for further use:

• The seller needs a list of possible buyers to notify about the receipt of goods
  
• The seller needs purchasing power forecasts so as not to oversell and alienate buyers
  
• Buyer needs manufacturer ratings
  
• The manufacturer needs the results of the activity of buyers, sellers, seasonal changes in activity, etc.
  
• It is necessary to calculate discounts, rewards, and other monetary relations
  

etc.
The volumes are now seen as follows: more than a hundred manufacturers, about a hundred sellers per manufacturer, and about several dozen buyers from sellers.
With great gratitude I will accept the experience of real design, as well as links to code, books and articles.

Answer 1

As a result, everything resulted in the normalization of the relational database. On relatively small volumes, everything plays without additional hassle (about a dozen sellers). HABTM relationships (there are many of them) had to be converted from anonymous to one-to-many pairs via an explicit object for clarity.