Hi really like the gem but noticed some inaccuracies with the README.md file
Schema multitenancy uses database schemas to handle multitenancy. For this approach, your database has multiple schemas and each schema contains your database tables. Schemas require migrations to be run against each tenant and generally makes it harder to scale as you add more tenants. The Apartment gem uses schema multitenancy.
This is only true for Apartment if using Postgres as the database solution, if using MySQL Apartment creates a completely separate database for each tenant and so avoids all of the issues with Schemas.
I only mention this as from a deployment and management perspective having separate databases adds a significant performance boost when using large tables and makes backups and restorations significantly easier than using a single database. But unless you modify Apartment to run migrations in parallel you are indeed still stuck with slow migrations.
Hi really like the gem but noticed some inaccuracies with the README.md file
Schema multitenancy uses database schemas to handle multitenancy. For this approach, your database has multiple schemas and each schema contains your database tables. Schemas require migrations to be run against each tenant and generally makes it harder to scale as you add more tenants. The Apartment gem uses schema multitenancy.
This is only true for Apartment if using Postgres as the database solution, if using MySQL Apartment creates a completely separate database for each tenant and so avoids all of the issues with Schemas.
I only mention this as from a deployment and management perspective having separate databases adds a significant performance boost when using large tables and makes backups and restorations significantly easier than using a single database. But unless you modify Apartment to run migrations in parallel you are indeed still stuck with slow migrations.
Hope this helps :-)