But it has serious downsides[1], which is a valid reason to forego it for applications that you already know will be complex in domain-logic, transaction-boundaries or where distribution and concurrency are crucial features.
Indeed, the tight coupling to the database is a real and felt problem. It makes migrations and deployments hard. And it makes layering your architecture almost impossible. e.g. I'm currently working on a Ruby (not Rails) application following the Hexagonal Architecture. Where ActiveRecord is powering the persistency adapter; away and aside. AR is not happy in that role. And we use hardly any features of AR, so it is overkill and will be fased out soon (we didn't design it this way, we merely moved the AR out of an existing tangled mess into its dedicated layer/adapter; the next logical step is to remove AR entirely).
ActiveRecord is an example of an ORM. ORMs are a very common way to connect an object oriented language with a relational database. Since many languages are object oriented, and the databases many people use are relational databases, this is a common solution.
There’s no reason why you have to couple storage interface to business logic.
I’ve done this before. Develop business logic as a separate gem and then include that in a Rails project.
ActiveRecord is actually entirely optional in Rails, it’s just the default.
You can also use POROs as presenters and mixin ActiveModel if you want things like validations.
Then couple that with Sequel as an alternative to ActiveRecord to run data access objects.
Sequel is often regarded as a more permanent alternative to ActiveRecord. It’s not a drop in replacement though so that might be a consideration for team skills/support.
I believe it's quite common outside of Ruby world - for example both Python and PHP have popular active record implementations (Django ORM and Laravel ORM respectively).
In Rails you can replace the ActiveRecord layer using regular Rudy classes that include some ActiveModel modules.
In this architecture, you’re using these classes to replace models. Which gives you a layer of abstraction between the UI and the database.
Querying becomes more difficult and some libraries won’t work out of the box, but it’s quite easy to implement.
Most people don’t do this because this architecture isn’t the default, takes more time, and requires a larger application to justify doing a lot of work twice.
It's not quite coupled to the storage, in that you can use a number of different drivers with ActiveRecord for the actual storage portion. But I think you might mean coupling the model so tightly to it's CRUD logic.
Inside the application you are actually trying to get all the benefits of having an Active Record model, not all the benefits of having a Car/Cat/Dog model. So you don't actually have a Car model, you have an Active Record model that represents a Car. Thinking about it that way I think sets the right expectations for what you're trying to achieve.
Is active record patern popular outside of Rails?