I am organizing a multi tenant application with a single code base/application using subdomains to detect the tenant, then runs a SET SCHEMA on postgres to do the fun stuff.
Would a hooks + plugins setup meet your needs? ie: build the additional functionality into another model, on whatever actions you need to modify check a hooks table to see if the user requires any extra actions, hooks table also specifies the action to take so you could easily setup different configurations for different users.
If you found a better answer to this please update.
If you're talking about switching databases on the fly between requests then I think you're in for a world of hurt, at least when it comes to using ActiveRecord. This will mess up the caching system severely as it remembers things based on ID, not ID + Schema, which could result in cross-contamination.
Generally, from an architectural perspective, it's best to partition your database internally and have every record scoped accordingly. For instance:
class Site < ActiveRecord::Base
# Represents a site or installation of the application
end
class User < ActiveRecord::Base
belongs_to :site
end
Link everything up to the main Site
record, or whatever term would best describe the method you use to partition. Maintaining a consistent scope is far easier than switching schema.
If, for reasons of scaling, you want to split the database in the future, if you've been careful to tag all of a site's associated records with a consistent site_id
column, you can easily transpose all of these records to a new database.