Multi-tenancy is a common strategy among Independent Software Vendors (ISVs), enterprises providing database-as-a-service (DBaaS) to different business units, or firms creating sandboxes for development and testing. It allows a single instance of an app and its infrastructure to serve multiple customers, with users sharing both the application and the database, but their data remaining isolated and invisible to others. Companies developing fully-managed SaaS solutions as replacements for traditional self-managed ones have brought multi-tenancy to the forefront, prompting discussions on when to use what approach. There are five (and a half) strategies that can be used to manage multi-tenancy: separating tenants by row, schema, database, table partition, and cluster. Each strategy has its benefits and challenges, and companies should consider their specific needs and requirements before choosing the best approach for their multi-tenant application. Separating tenants by row is suitable for achieving the lowest management overhead when onboarding new tenants, simplifying access controls, running a single application version for all tenants, and navigating complex backup and recovery per tenant. Separating tenants by schema makes sense in scenarios requiring high data isolation between tenants, customizable schemas, combining data across tenants, or taking on additional maintenance activities across tenants. Managing application releases simultaneously for all tenants while controlling the data placement is achieved through separating tenants by table partition. This approach is suitable for large numbers of tenants with varying data separation needs, flexibility in managing application releases, and controlling data placement per tenant. The primary goal is to achieve the lowest possible management overhead, with or without row-level security. A combination of "Separate Tenants by Row (With or Without Row-Level Security)" and "Separate by Database" can be used for a tiered-based tenant approach, leveraging the advantages of each method according to tenant needs. Finally, separating tenants by cluster is suitable for high data volumes and requiring one's own cluster, while smaller tenants can reside on a single cluster.