Hello!
Rails has always had support for a wide range of SQL database engines. MySQL, Postgres, Oracle, MS-SQL, FrontBase, SQLite, etc., and a fair number of non-SQL databases like Mongo and the like. This is all handled at the database adapter level, and even if Rails proper doesn’t carry an official adapter, there are third-party adapters (I’m thinking here of Oracle, which I use at work). In this earliest and simplest form, Rails’s multi-database feature referred to being able to support one application and all its models with one database (at a time).
Every Rails since version 1 has been able to connect the same application code (Ruby) to one database for test, another for development, and yet another for production (and more, those are just the basic 3 environments you get “for free” when you spin up a new application) if you wanted or needed to do that. The unsung benefit of the ActiveRecord ORM is that the underlying database is just dumb storage, and you don’t have to code specifically to it if you don’t want or need to.
(Some will argue, and provide splendid examples of why you would like to do just that, and they are also correct. When you get beyond Hello World, and “Whoops, a blog” examples, you often find you need to get into the metal of a particular database to do something that ActiveRecord doesn’t support directly. That’s not an argument against the inherent flexibility of an ORM, but just a way of measuring how successful you are. Generally, you don’t run into these problems without becoming Twitter-scale popular, and then you can usually afford to solve those problems by hiring a DBA and some more programmers.)
Rails 6 introduced a new feature allowing multiple databases to be used at one time in the same application*. This feature, which I have not used myself yet, allows you to have all sorts of flexibility around database connections. Having some be read-write and others read-only appears to be a banner feature. The way that Rails 6 has architected this, you can use multiple databases with a single model, or different databases with different models, or maybe have a read replica that only is used when servicing GET requests – the sky is really the limit.
I would surmise that, given some effort and study on your part, you would be able to stand up an intranet with multiple database connections to heterogenous RDBMSs. That seems very much to be a feature that’s in Rails 6’s wheelhouse.
Walter
*I have done a very low-brow version of this feature, usually for data migration reasons, as far back as Rails 3, and it’s not hard, but it’s definitely not what I’d like to run the whole application on full-time. It involves creating new ActiveRecord::Base instances with different database connections, and basing your separate models that relate to the secondary or tertiary database on those Bases, rather than your central ApplicationRecord.
