With raster tiles, you can either generate them in advanced and cache them OR you can tell the server to generate them as they are requested and cache them "on the fly". Over time the cache grows anyway and service is slower until the cache has been built. So it's easy to publish and if you have a small user base (like me) there will almost never be tiles pre-generated so almost everyone gets a slowed down page load.
With vector tiles, the tiles are never generated on the fly. You always generate them in advance. You can either generate them on a desktop and upload them ("hosted") or you can generate them from registered data. When you generate them from registered data, first a feature service is created and then the server generates the vector tile cache.
That means the vector tile cache is still "hosted".
The advantages? The "copy all data to server" option does not publish a feature layer. If you don't need one, this is a bit simpler. If you want popups to work you need a queryable layer so you need the feature layer anyway. If you use registered data, then the queries hit your database, that's possibly faster or slower for you.
If the attributes for a vector service get updated more often than the shapes, then you don't have to refresh the service -- queries go to the database anyway so they are up to date always.
When you want to refresh the shape data, you can just click a button in Portal to tell it to "Rebuild Cache" on the "details" page for the service. (I assume there's a Python call to do this too?) Then wait. I think it probably builds an entirely new cache internally and then swaps them when the rebuild is completed. I don't have a way to confirm that. But it appears that the old service remains available while the rebuild is happening.
I think that answers what you asked? (1) If you use registered data + vector, queries will go to the server and (2) it lets you do rebuilds more easily.
CURRENTLY I generate some vector layers on my desktop, and then publish them under a new name, then I can proof them and then finally I can use the "replace layer" feature to switch to the new service. I wrote a script to handle all this -- publish is step 1, then in step 2 I do Q/A, then in step 3 another script does the "replace".
I have been testing the "registered data" approach, but so far it's not working for me. It's the fact that I have no control over how many vector layers are generated. For my basic map (roads, parks, water) I normally have a layer with all the labels in it and a layer with all the shapes in it. I have one feature service ("Roads") that I use for popups.
If I let ArcGIS Pro squash all the layers into one, then I cannot put anything on top of the vectors without obscuring the labels.
I guess the only way I can get what I want currently is to continue doing what I have been-- I have to have several maps, one for the labels, one for shapes, and manage them separately.
It's getting more complex since I am now going to switch from using feature service for taxlots to using a vector tile layer. So I will be adding about 4 more maps to manage the whole thing...
If you publish a vector tile service with registered data, on the Portal page you will see also an option to publish attributes with the tiles. This is needed. But it does not work. On server 10.9.1 a message pops up "Unable to configure the attributes at this time."
A quick search here will show you this that Esri has promised a queries feature since at least 2018. Must be hard to implement.
