Sure. Basically, I have a schema called template_tenant, and a table public.tenants (ie. in the public schema). For each record with id n in the public.tenants table, I have another schema tenant_n cloned from and kept in sync with the template_tenant schema.

The result of this is that I have dozens of tables duplicated across n schemas. In Rails 3.1, the Postgres query cache, exec cache, and the identity map do not account for this, nor does table_exists?, and the connection pool would often check out a new connection without preserving the search path.

In Rails 3.2, most of these are fixed. The exec cache, query cache, and table_exists? now observe the search_path properly, and I believe the connection pool behaves better, though I haven't had time to confirm that. The identity map still doesn't understand, which I've filed an issue for: https://github.com/rails/rails/issues/4044

I'm really happy with this pattern for multi-tenant apps. It gives me a lot more confidence that no data leaks will happen than scoping queries, and the performance increase is significant with large datasets (unless of course, for some reason, you need to aggregate across tenants). It's nice to see rails supporting this better.

The sixth patch I had hacks support for iterating over multiple schemas to migrations. I add "schema_set :public or :tenant" to the top of my migration, and it runs either once on the public schema, or n+1 times on my template_tenant schema and my tenant_X schemas. It wouldn't make sense for this part to be in rails proper at the moment.