(co-founder of Nile here)

You are right, it is hard to cover everything in one blog...

But the gist is that schemas and all the objects in them have few significant drawbacks:

1. Catalog overhead. Each schema has all the objects. PG Catalog doesn't scale to huge numbers. If you test anything that needs to work with the entire catalog, you'll run into issues in the 4-5 digits range (depends on number of tables, indexes, etc).

2. If you need to write a query that executes on all schema and aggregates results (for a report or something), you need to build your own tools.

3. Schema migrations and DDLs are increasingly hard to coordinate (I gave a whole talk about that here: https://www.youtube.com/watch?v=Nnz4VesXyUA

We basically didn't just build the distributed query and DDL layer, we also did some smart things in Postgres itself (blog TBD) that allow us to reduce the catalog overhead significantly.

We mention that there is a spectrum of solutions to this in the blog but plan to go into it in a separate blog. The main thing is that users no longer have to think about any of these options. Nile does it natively by having a page per tenant architecture and can move tenant's data between computes.