Top level databases hierarchy logic

Help
1

Going through tutorials and easing into it, trying to understand best practices.

A little confusion came from the following: I make the first db at top level online, then create a key, then go work at my local shell and make the first db. Then I go back online, and my db is nested under the db first made online. Ok, that makes sense because it is under the authority of the parent key I logged into the system with through my local shell.

However, on the Fauna dashboard at top level, the databases created at this level are not called databases. Are the top level databases more like projects or apps or schemas? Moreover, for development purposes, if a developer admin starts at the top level, then the top level key should be enough to access any child databases in this application/project?

What I am trying to understand is the multiple tenancy vs different projects or apps at the top level. Are there documents that explain what the best approach is for a developer that may work on different projects or related projects with common functions?

Also, is there documentation covering how to log in with multiple keys that relate respectively to multiple projects? I have not found this, but would appreciate a good direction.

Thanks in advance.
Radu

1 Like
2

It’s indeed common confusion because we don’t provide a ‘root’ key.

This confuses me slightly, my databases are called databases so I’m not certain what you mean.
image

With a top level admin key you can indeed gain access to child databases.

There are documents on multi-tenancy but they might bias you towards using multiple databases for everything which is definitely not the best choice. The question always comes back to: “do you need transactions over the data stored in these multiple databases or not since we don’t provide that yet”. A lot of answers have been provided in other forum posts that might help you:

3

Thanks for the responses. Real quick: theoretically, it is quite doable to read/write data among the child databases of a one parent, top-level database, correct? Which is not the case, or maybe it’s much harder to, read/write data between say two top-level databases?

4

Yes, but not in one transaction. The difference is minimal though. What you would do for child databases is:

  • Get a top level key
  • Use the top level key to get a key to child database 1, then read/write with that key
  • Use the top level key to get a key to child database 2, then read/write with that key

What you would do for two top-level databases is:

  • get two top level keys.

The main difference is that you have one powerful key who can manage your child databases.

1 Like