# Hosting many forums on a single Discourse instance with a single database

**URL:** <https://meta.discourse.org/t/hosting-many-forums-on-a-single-discourse-instance-with-a-single-database/21556>\
**Category:** Feature\
**Created:** [10월 27, 2014, 10:35오후 UTC](https://meta.discourse.org/t/hosting-many-forums-on-a-single-discourse-instance-with-a-single-database/21556 "2014-10-27T22:35:32Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![jmay](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jmay/32/108427_2.png) [@jmay](https://meta.discourse.org/u/jmay)\
**Post date:** [10월 31, 2014, 10:15오후 UTC](https://meta.discourse.org/t/hosting-many-forums-on-a-single-discourse-instance-with-a-single-database/21556/7 "2014-10-31T22:15:02Z")

</div>

I’m thinking of an environment where there are thousands of forums, most with very light activity. Creating entire sets of tables for every one of those (as in the apartment gem) is terrifying. e.g. on software updates needing to run the migrations against N tenants. And I want an environment where provisioning a new forum is a fast & lightweight operation.

But I see your point on adding scope columns to the major tables. Probably not to everything, but it would be nice to avoid it even on the main ones. And then needing to add `.where(forum: current_forum)` everywhere just dirties up the codebase.

I’m going to keep hunting for alternatives. Would like to minimize overall impact.

---

_[View the full topic](https://meta.discourse.org/t/hosting-many-forums-on-a-single-discourse-instance-with-a-single-database/21556)._