Useful or not, from you.
codecarbon Codecarbon Database Schema

By @alencon :

That's a useful answer
Without any help

I can discuss how our namespaces are structured. Each comet_ml.Experiment have an unique ID, generated on the client side (with uuid.uuid4() basically). Each experiment uses a single API Key attached to a single user. Each user has a default workspace (named after the user) and inside that workspace there is a default (private) project named general. That means when sending data (and if the user don't provides a workspace or project_name), we can find "where" to store the data.

Users can also provide a workspace name and/or a project name. If the workspace exists and if the user has permission to write in it, we store the data in the provided workspace and/or project.

Projects (and experiment) are automatically created but workspaces are not. Permission are managed at the workspace level and each workspace admin can add other members to read and/or write to that workspace.

Namespaces (or team/project/organizations) design often comes to solves permissions requirements, how are you envisioning read/write permissions?