Sorry for the confusion, I used the term ‘WebAPI database’ earlier, and I would have said ‘OHDSI’ database if I had known that’s the label you’re putting on the database that WebAPI references in its configuration.
The CDM database is a separate database from the OHDSI database. You can have many CDM databases configured and referenced by a single WebAPI instance (stored in the ODHSI database). In the OHDSI database, the tables that WebAPI uses (and automatically manages) are found in the webapi schema.
Technically, you CAN put your individual CDM databases into separate schemas within your OHDSI database.
The separation I’m suggesting, tho, allows you to set up different failover and redundancy configurations for your WebAPI database (which is heavily transactional) vs your CDM datbases (which is lightly transactional but only in the ‘result’ schema where the output of an analysis is stored, such as cohort generation, or characterization).
The accounts used to access WebAPI also have elevated permissions to alter WebAPI tables between version updates, and those elevated permissions would never be used against any of your CDM schemas, so that may be a security concern.
Typically, CDMs require far more space and have different operating characteristics than the WebAPI database…WebAPI may have several thousand rows of data in it, while CDMs may have billions. So your hardware configuration may be different to support WebAPI workloads comapared to CDM workloads.
You may want to take certain CDMs offline independently of the WebAPI database.
So, many reasons to separate those, so I’d just get comfortable with that configuration now instead of trying to separate ‘internal schemas’ from WebAPI later when you wish you’d set it up as separate databases.