Yeah absolutely, I definitely can’t be rendering a whole planet as voxels at once as such. That would be a bit bonkers to try haha. Although it depends on Codeas abilities with its craft built in voxels/chunks, with considering Codea must be culling, geometry, voxels and possibly chunks too. My general though process was taking the same sort of approach of streaming, on the fly, like games such as GTA is a well known example, as well as also being how NMS accomplishes the same too. You only really need to worry about drawing what the player can “see”, although the hard part is working out what their view is precisely and what that means you draw and don’t draw.
For streaming asynchronously, this is where the Task classes functionality comes in, significantly with using coroutines to do background work, arbitrarily in terms of work function definition, which I am then using timing small amounts of work being processed before yielding / sleeping until completed. Which is all then driven from the draw/update function based hook calling Tasks.update().
While often in most games, and particularly in games with dynamic worlds. Streaming conditional and/or ‘viewport’ dependent drawing, as in a frustum hit detection algorithm for example, is based in approaches needing an efficient structure to “look up” your entities and drawables, collisions etc within the games logic. Then handle them conditionally as needed, e.g. to swap an entity to visible and being drawn by Codea or invisible not being drawn, saving Codea processing. If you can make it cheaper than just drawing everything to screen that is anyway.
Which then in circumstances like this is where structures, like a tree, come in. For example the quadtree implementation posted recently by @Kizik or the extra dimensioned / bucketed cousins octrees. That arrange and store entities in a similar structural approach to a binary tree, except by dimensions in terms of position vectors, if I recall correctly. So you have one bucket each for example for, +x,-x,+y,-y,+z,-z. So by inference here as you can kind of see from +x,-x and +y, -y dimensions, a quadtree is more optimised for handling 2D vectors. Where as in 3D typically being more complex, off the top of my head and again if I recall accurately. An octree becomes required as you effectively need a x/y/z position and a direction vector like vec3.forward to resolve a position / cast a ray along, a 3D line / effectively drawing an infinite tube out in a direction and angle. That is effectively ‘drawn’ in 3D space by a ray casting algorithm to see what it intersects with, in terms of hit boxes or geometry of entities.
Hope this helps explain my thought process a bit more, although I’m omitting a few particulars in order to keep some things hidden up my sleeve as it would be…until the time then comes to reveal them in a hopefully refined state 
… eventually 