Design problems of ActiveRecord for large application

Laravel and some another framework provide Active Record conception in their base classes of model. The main idea of Active Record is a representation of table row as an object that includes data of a row and methods of work with databases.

Using of Active Record pattern is fully justified in small simple applications because this pattern gives an ability to fast develop your application. But if your application has a lot of code and difficult business logic, Active Record will make many problems in the architecture of your application. Active Record can make the following problems:

• violation of the Single Responsibility Principle that makes bloated code. Active Record always violates this principle, because it always has two responsibility: it implements business logic and methods of database work
• violation of low coupling principle (GRASP) that makes code reuse more difficult
• сreation of qualified abstraction is difficult if you use Active Record pattern

The solution to those problems is using of OOP abstractions instead of using of table rows abstractions. For example, you can use Domain Model and Domain-driven design. This approach is better than Active Record pattern for large applications.

Unfortunately, those concepts are too large-volume for explanation in this post, but you can read "Domain Driven Design" by Eric Evans. It is a good book about application design. Also, you can find many articles about those concepts in google. For example Building a Domain Model, Implementing Domain-Driven Design in PHP (Laravel)

The class could become 10k lines of code or so

Each relationship function is 2-4 lines of code so unless you have 2500-5000 relationships, this class is not going to be 10k lines of code. If you do, you already have bad database design.

Also the Single Responsible Principle maybe is violated because you have too many methods in one class.

Nowhere does the SRP state that you cant have too many methods in one class. It states that a class should have only a single responsibility/reason to exist.

Also if I want to use the class it in another app I cannot, simply because I'll have to pull also the pictures, comments and etc in the second application(website).

This class is a Model class. Its responsibility is to represent one database table. If you have the same table structure in other apps, then yes, you should pull in this class and you would need to pull in pictures, comments, etc. as well since you have the same table structure. If not, you shouldn't pull it in. I don't see any problem here.