ArcGIS hosted data services: Creation and maintenance differences

ℹ️ This blog series focuses on hosted data services in ArcGIS Online and ArcGIS Location Platform (more about the scope).

Having covered what they are designed for and the use cases they best support, this article takes a deeper dive into the technical differences between them in terms of creation and maintenance.

You will learn some aspects that aren’t required for using them, but can make a difference when it comes to creating and maintaining them:

• What data each service type can store.
• How data is structured and stored.
• How services handle updates and edits.
• What’s inside a service definition.
• How tiles are generated and how long it takes.
• How much storage does each service consume.
• Using services offline.
• Where to go from here.

This article is considerably more technical than the previous ones. It is primarily intended for technical profiles: developers, data engineers, solution architects, technical product managers, and anyone responsible for making decisions about data architecture or the integration of storage and processing technologies.

The more ‘practical’ part, understanding how to work with these services, will be covered in the following article: “ArcGIS hosted data services: Management tools differences” (coming soon).

[TL;DR] If you don’t have time to read the whole thing, this table gives you the highlights at a glance:

Now let’s explain this table.

What data each service type can store

• Hosted map tile services: The only one of the three that supports both vector datasets and raster images, such as satellite imagery and continuous datasets (e.g., elevation, weather maps, or hillshades). Regardless of the source, the data is rasterized (converted into pre-rendered image tiles) for performance, visual consistency, data protection, or compatibility with clients that have limited rendering capabilities. Examples of rasterized vector datasets include:
  • Feature geometries: points, lines, polygons (e.g., roads, boundaries, building footprints).
  • Labels and cartographic symbols: text (e.g., street/place names, dimensions) and graphic elements (e.g., arrows, shields, charts).
  • Complex cartographic styles: textures, drop shadows, glows, blend modes, or proprietary fonts/icons.
• Hosted vector tile services: Support vector datasets only, such as store locations, delivery zones, postal codes, road networks, and building footprints. They also support attributes that are typically used to render map symbols and labels, but can also be utilized for client-side filtering, and popups/hovers.
• Hosted feature services: Support both vector datasets and non-spatial tabular data, each with associated attribute information. Non-spatial data is commonly used for:
  • Related records, such as multiple inspections linked to buildings.
  • Lookup and reference tables, like codes, categories, or other shared values.
  • Standalone tabular data, such as inventory or contact details.
  • Form responses, logs, or transactional records.

How data is structured and stored

• Hosted map tile services and hosted vector tile services are optimized for fast visualization using pre-rendered static files stored on disk, meaning they both lack a relational structure.
• Hosted vector tile services store simplified geometry. They usually store a subset of the attributes from the original dataset required for rendering the map. Still, you have the option to embed additional attributes for client-side use. Keep in mind that all attributes are downloaded with each tile, even if unused. Extra attributes increase tile size and memory usage, which can affect the app’s performance.
• Hosted feature services store data in ArcGIS-managed relational storage, with geometry types kept in separate layers and standalone tabular data. They enable advanced capabilities like relationships (foreign-key–like links), layer views (similar to SQL views), attachments (BLOBs), domains (ENUMs), contingent values (conditional ENUMs), subtypes, and more.

Note that non-spatial tabular data can exist either as standalone tables or linked to spatial layers. In both cases, it supports querying, editing, and relationships.

How services handle updates and edits

• Hosted map tile services and hosted vector tile services. If services are published as “standalone” (from a file, such as a tile package or vector tile package), updating any change in the source data would require republishing the entire tile set, which can be resource-intensive for large datasets. When published from a hosted feature service, you can update (rebuild) cached tiles for specific extents, and vector tile services also allow you to schedule cache rebuilds.
• Hosted feature services are the only ones that support dynamic editing (e.g., immediately update individual features, fields, attachments). They can also emit webhooks, making them suitable for reactive systems.

What’s inside a service definition

The service definition is a structured JSON object that describes all key aspects of a service or layer.

Below are some of the most relevant elements commonly included (though this list isn’t exhaustive, as these definitions continue to evolve over time):

Shared service definition elements

All ArcGIS hosted services (regardless of type) share some basic definition elements:

• Service metadata: Name, description, tags, type, etc.
• Spatial reference: Coordinate system used.
• Extent: Bounding box of the data.
• Export support and other technical parameters.

Hosted map tile services

They offer the most limited service definition among hosted services because they rely on pre-rendered raster tiles.

Their service definition focuses on rendering and delivery settings, including:

• Tiling scheme: Defines how the map is broken into tiles (e.g., origin, tile size, image format, DPI, levels of detail (LODs)).
• Available scales: maximum and minimum scales.
• Capabilities: export tiles, update tiles, import tiles, and delete tiles.
• Export and access limits: exportTilesAllowed and maxExportTilesCount.

Hosted vector tile services

Like map tile services, they also include rendering and delivery settings, as well as:

• A style definition: references a JSON object that defines the default style of the features and labels, much like how CSS controls the appearance of HTML elements. Including:
  • Fonts, symbols, color schemes, and visibility rules.
  • Resources like sprites and icons.
• Some additional properties when published from a hosted feature service, such as layerProperties, which define additional attributes from the service, should be backed in the vector tiles, or sourceServiceName, indicating the name of the hosted feature service from which it was created.

Hosted feature services

They include the richest and most editable definition, including:

• Fields definition: Fields and geometry types, attribute domains, subtypes, relationships between layers/tables, contingent values, and true curves (also known as parametric curves).
• Layer style definition (stored in the service): symbology, labeling, and rendering rules.
• Capabilities: Access control and editing capabilities (including who can create, query, delete, update, and edit), enable offline sync, rollback behavior for batch edits, and configure spatial and field indexes.
• Other settings: configure maximum records per query page, CDN cache configuration, and more.

Reminder: For organizations that want to offer access to their data using interoperable OGC standards, it is worth remembering that hosted feature services, in addition to map tile services and vector tile services, can also be published under the WFS and OGC API – Features.

How tiles are generated and how long it takes

• Hosted map tile services and hosted vector tile services can be published from hosted feature services, which have several advantages, including on-demand tile generation, as well as making it easier to keep tiles updated with edits in the source hosted feature layer, etc. But keep in mind that these benefits may also incur variable costs based on usage (more on this topic in the blog: “Understand Service Usage Differences”, coming soon).
• Hosted map tile services: When published from a static file (a TPK or TPKX package), all tiles have already been pre-rendered as raster images (PNG/JPEG). These tile packages are typically generated in ArcGIS Pro on a self-managed computer, which can be time and storage-intensive for large geographic regions (learn more about this).
• Hosted vector tile services: When published from a static file (a VTPK package), all vector data have been encoded as vector tiles (as PBF). As with map tile packages, they are usually created from ArcGIS Pro. They are faster to generate and more lightweight than map tiles.
• Hosted feature services: As we already mentioned, these are not stored as pre-generated tiles. They serve data on demand (tiled or not), querying features directly from the relational database. However, they do support repeatable spatial queries (such as map extents or tile boundaries), which can be stored in intermediate services (like the CDN), and in the default cache in clients. This allows for a hybrid performance model: data can be cached for fast read-only access in high-demand or near-real-time scenarios, while still providing full access to the underlying feature model, including editing, querying, and relationships.
• Note: The processing time for a hosted tile layer cannot be predicted with precision. It depends on factors such as the size and complexity of the data, the service type, the spatial extent, and whether tiles are generated on demand or pre-generated (and for how many zoom levels). In most cases, tile generation takes from a few minutes, but can take up to several hours. Massive raster datasets with global coverage and many pre-generated zoom levels can take several days to process.

How much storage does each service consume

• Hosted map tile services require significantly more disk space than vector tiles, especially at large scales or when covering large areas.
• Hosted map tile services and hosted vector tile services: When published from separate tile packages, these services take a fixed amount of disk space. However, when published from a hosted feature service with on-demand tile generation, storage starts small and grows gradually, as tiles are cached and stored only when they are requested. In such cases, it’s important to consider the underlying storage used by the associated hosted feature service, especially if that feature layer exists solely to support tile generation.
• Hosted feature services are highly variable and can use more storage than tile services because they rely on a relational database model that stores more attribute data, multiscale geometries for each feature (if you enable drawing optimization), index tables, etc. However, hosted feature layer views do not consume any storage because the data isn’t duplicated.
• All services, when published from a local file, the original file remains in your content as a separate item. The hosted layer is linked to the file as its source. This means that if you attempt to delete the source file, the Portal may warn you that the hosted layer depends on it. You can still delete the file, and the hosted layer will continue to function, but you’ll lose some capabilities.
• Note: It isn’t possible to estimate storage size for any service type before it is published. It depends on several factors, primarily the size and level of detail of your data, the spatial coverage, and the number of zoom levels. A recommended approach is to publish the service first and then check its reported size afterward. Note that some services may take up to 48 hours to display accurate size or usage statistics in the portal. Learn more about how usage works in “ArcGIS hosted data services: Understand service usage differences” (coming soon).

Using services offline

• Hosted map tile services and hosted vector tile services can be used offline in native apps (mobile and desktop).
• Hosted feature services can also be enabled to be taken offline (via sync-enabled replicas), while maintaining the possibility of making offline edits and then synchronizing them.

⚠️ Note: Although technically all services can operate in offline mode, ArcGIS Location Platform users must request authorization, as we will describe in the “Terms of Use & Pricing Differences” article (coming soon).

Where to go from here

We hope this article has clarified how these services store and generate data, what metadata they provide, and how they differ in key aspects such as updates, edits, tile generation, storage consumption, and offline use. With this understanding, you’ll be better equipped to evaluate their advantages and limitations, as well as to design a more efficient spatial data infrastructure.

To learn more, see the Portal and data services guide and the Intro to Caching with ArcGIS Pro video series.

We encourage you to check the next article, where we’ll look at tools, mechanisms, and utilities available to manage these services: “ArcGIS hosted data services: Management tools differences” (coming soon).

If you have any questions or want to dive deeper, join the discussion in our community forums: Esri Community > Developers > ArcGIS REST APIs and Services > ArcGIS Location Service.

Lastly, if you found this article helpful and believe others in your professional network may benefit from it, we would greatly appreciate it if you could share or engage with the post on LinkedIn, Bluesky, or X.

Thank you to everyone who contributed to the content of this article. You rock! Extra special thanks to Tommy Fauvell, Matt George, Chris Wesson, Yue (Nathan) Wu, Nico Loza, and Mark Torrey.