All of these tables should be on the server.
Whether your "tree building table" will result in one user's data interfering with another depends on how you set up your system to manage them and you can set it up to keep the records from one user from interfering with another. Each user's records in this table, for example could have a field that contains the account name of the user that created them. The value in this field can then be used to keep one user's set of records from interfering with another.
Yeah, I was wanting to avoid doing something like that. I guess I don't have a choice. I have another solution where I use Postgresl as the server and FileMaker as the client. I designed a 'client' file in FileMaker that pushes and pulls data from the Postgresql server as required. It works quite well for that solution. In this case, I want everything on the server if possible. I'll have to work something out where I can isolate each users records in separate tables. Your suggestion, or something like it, I will have to save as a last case scenario -- although, I don't know what the alternative would be at this point.
I strongly, strongly advise AGAINST "isolate each users records in separate tables"! This is NOT what I am recommending. Keep all of your records in the same set of tables for all users. But then use the tools any relational database comes with to keep different subsets of records accessible for different users.
That's why you would "mark" all records for a given user with their account name. That, for just one example, allows you to script finds that only find records with the user's account name. In another example, it allows relationships and portal filters to limit related records to only those with the current user's account name. And you can set up manage security to limit the user's access to only "their" records. This can be to the point that the use never even knows other records exist..