Read on Twitter
1/ Some of the challenges with postgres-schema multitenancy stem from its *statefullness*.
In most solutions tenant switching relies on search_path and basically looks like this:
In most solutions tenant switching relies on search_path and basically looks like this:
2/ More precisely: the challenges stem from the fact that the state lives in the current postgres session.
Example challenges: PgBouncer transaction mode, multiple threads, additional db connections.
Example challenges: PgBouncer transaction mode, multiple threads, additional db connections.
3/ It's all solvable, but perhaps it could be more robust if we went for a little crazy idea to change ActiveRecord table names on the fly?
Of course it's just a PoC, perhaps it'd be an overkill to do on each request. Also, thread safety. Maybe we could monkey patch ActiveRecord's table name getter to to consult a variable.
Anyways, this wouldn't be fully stateless, but at least the state would now live in the app.
Anyways, this wouldn't be fully stateless, but at least the state would now live in the app.
For more multitenancy ideas tune in today at 20:00 UTC: https://railsarchitects.com/conference/
An example of aformentioned "challenge":
