Saving data about 3D objects in new GLB file or in Database?

I have an app that uses ThreeJS where the user can visualize 3D models and some data. I would like to know when a user modify/edit some properties of a 3D object in ThreeJS (say color, position, or userData), what is the good practice on how to save the data ?

  • Option 1: Is it better to make a file export with the new data embedded in the glb/gltf file and save it into a storage service (S3 for example)
  • Option 2: or is it better to keep the same glb model (unedited) but save all the attribute values, edits and additions into a database (MongoDB for example). We would have a 3Dobject Collection with documents for each 3D object and its attributes (color, position, scale, userData, etc.)
  • A combination of both options ?

I wanted to know what’s the best approach in tackling user changes of the scene.

Any insights or experience shared is much appreciated

I have a similar situation and elected for model + data in db.
The advantage is in reusing the same glb in several objects (for caching and performance) and updating a single model updates all derivatives.

1 Like

Thanks for your input Peter,

So if I understand correctly, one option (most likely the best option) is to keep the model untouched, and store all relevant variables in DB.
If we take an example, we would have a glb model with many meshes, where each mesh would have a unique ID stored in UserData (NOT the threejs UUID of the mesh as it changes on each page refresh) to identify it in the Database. One way to handle the changes, is to keep track of all the changes (front End as an example). When the user is ready to save the changes, then we write these changes in database using the unique ID for each mesh.
Does that make sense or am I not getting this right ?
Thanks for your insights on this

Hmm, many meshes in one .glb?
Might not be the most flexible, or efficient for loading over a network.
Would need to know more about your application…

1 Like

The glb would contain somewhere around 50 to 100 meshes (different meshes so instancing is not an option…). The total glb file size when compressed would not exceed 5MB. My worry is not loading the model but how to keep track of the user changes ?
It seems to me that it’s tedious to keep track of all the relevant attributes for each mesh in the DB and update those when changes occur

Why lumping all your meshes into a single glb?

Not for a specific reason. Because it is possible.
What would be the alternative ? have many glbs, one glb per mesh ? The question remains, do you edit the glb directly (overwriting the old one or creating a new one in the storage service) or do you write the edits into the DB, leaving the glbs untouched ? what’s the good practice ?

All depends on the use scenario.
I maintain trinityjs (, a server for serving .glbs. My biggest customer make children’s beds, that are modular. In that scenario it makes sense to have everything in separate .glb’s (containing one or more meshes) that can be streamed to the client depending on which bed they choose to load or re-configure.

What doesn’t make sense is to download a large .glb file, where you are only going to use a few of the assets (meshes, materials) that are inside.
We go even further and handle materials separately, so that if more than one model uses the same material, the maps are only loaded ONCE to the graphics card.