"I think it would add a level of complexity to the app"
... opposed to what - using just one schema for all tenants?
Then typically the opposite is true. Implementing multi-tenancy in one schema adds the complexity to each and every table where the data might belong to different tenants, which means this kind of complexity will go also into your app. Especially when there are lot of tables, having separate schemas actually reduces the complexity of your app. Make the schema a run-time configurable parameter, then you can develop your app almost as if there is only one tenant.
Moreover, it makes individual administrative tasks like individual backup/restore per tenant a hell lot easier. You could even allow different tenants having different versions of the schema in production at the same time.
Having one schema for all tenants is only beneficial if a big portion of the data in the schema is the same for all tenants, and that data is not individually managed by the tenants.
Of course, what you should avoid in a multiple schema approach is different schema customizations for individual tenants - that would indeed add a kind of complexity you want to avoid. Make sure schema changes are always implemented by versioned scripts (and not "on the fly"), so you can run those scripts against all schemas automatically (you need those either, even when using a single schema, since you typically have at least a dev database, a test database and a production database to manage).
Depending on the DBMS, you could also consider to use different database instances, which might give you a better scaling experience. For a system like Oracle, different schemas might be the better option because of the administrative overhead of managing different DB instances. For a system like MySql, different database instances might be a valid, maybe better approach (depends on your case).