ArcGIS Hosted Services Explained: Feature, Vector & Map Tiles Services

You can also find a Spanish translation of this article: leer en español 

What exactly is an ArcGIS feature service, and why is it considered so special? What are the differences between feature services and vector tile services? How can I optimize performance and cost by combining these services? How do I automate their creation and maintenance?

If any of these questions resonate with you, then this blog series is for you, we’ll explore all of these topics and more.

It is designed to help developers, solution architects, data engineers, and other technical decision-makers understand the differences between these widely used ArcGIS-hosted data services (available through a consumption-based model) and how each is specially optimized for different use cases:

• Hosted map tile services: for large amounts of static geospatial data.​
• Hosted vector tile services: for large geospatial data that doesn’t change frequently, supporting customization and basic interaction.
• Hosted feature services: for large, highly interactive, and editable data that needs to change efficiently.

⚠️ Important note: If you’re new to working with geospatial data, I highly recommend you read “What’s special about geospatial data?” before diving into this series. It will help you better understand the value these services provide.

⊕ Other ArcGIS data services

Keep in mind that in addition to the three services covered in this series, there are additional popular data services within the ArcGIS system optimized for other purposes, such as imagery (hosted image services and image services), 3D services (including 3D scenes, 3D tiles, etc.), real-time datasets (stream services), and others to work with big data, and more.

Content focus

This serie focus specifically on these three cloud-hosted services managed by Esri, which are available as Software as a Service (SaaS) and Platform as a Service (PaaS) through ArcGIS Online and ArcGIS Location Platform.

While these services are also available in self-managed environments via ArcGIS Enterprise, we won’t cover them here to keep the focus clearer, as they involve a different set of considerations.

We will also not include code samples and very few implementation steps; however, we’ll link to relevant resources from the Portal and data services guide, as well as other documentation pages when needed.

Why learn about ArcGIS hosted data services?

Sometimes you need to scale your infrastructure and reduce operational overhead. Using managed services lets you offload many technical complexities. Having cloud-hosted services to store, query, and update spatial data efficiently allows you to focus on the things that matter the most, delivering real value to the end user.

This is where ArcGIS hosted data services come in. They are the result of decades of experience supporting hundreds of thousands of organizations in the geospatial field. They can seamlessly complement your existing infrastructure, reducing your workload and making your life easier.

They also offer interoperability benefits, as they can also be exposed using open standards like OGC APIs, de facto standards like tiled web maps (also known as XYZ tiles*), MVT, and widely adopted plain-text formats like GeoJSON, making them easily accessible from both Esri and third-party clients*.

Throughout the series, you’ll also see comparisons with other technologies you may already be familiar with, to help you understand where they overlap, how they differ, and in which aspects the ArcGIS services stand out.

Why are we writing this series?

You might be wondering why we decided to write this series of articles when official documentation for these services already exists. I’m glad you asked! 😁.

The main reasons are:

• Some low-level technical details aren’t covered in the official docs. While not required to use the services, they help you understand the differences between them and choose the best fit for your needs.
• There are some advanced workflows and tools for highly automated use cases that aren’t widely known.
• Technical and business documentation are not always closely connected, making it more challenging to make decisions that involve both perspectives.

That’s why we created this series: to provide you with a focused resource you can use, to help you:

• Evaluate *which service is best suited for each dataset and workflow.
  *
• Reduce the learning curve, speed up the integration process, and reduce the maintenance work you will have to do
• Learn how to enhance the end-user experience of your applications.
• Reduce the associated costs.

That said, it’s also important to keep in mind that both the technology and the business model evolve rapidly, which means some details mentioned in the articles may become outdated over time. For this reason, each article includes references to the official documentation, where the most up-to-date information can be found.

In case of any discrepancy, the official documentation takes precedence over all other content.

By the end of this series, you’ll be able to clearly distinguish the capabilities, use cases, and trade-offs between these services. And you will be able to fully understand the following diagram that illustrates some of these differences:

In addition, your team will know which option is the most suitable for hosting each dataset based on your specific needs and preferences, as well as how to combine them within your applications.

Next steps

As mentioned at the beginning, this blog series is designed for different types of roles involved in using these services. The following table summarizes what each post will cover, who it’s intended for, and what you can expect to gain from reading it:

Article title	Who it’s intended for	What you’ll gain from reading it
Use case for each type of data service (coming soon)	Product managers, product owners, and solution architects.	Develop a clear mental model of what each service is best suited for (before diving into details).
Creation and maintenance differences (coming soon)	Data engineers, developers, solution architects, and technical product managers.	Understand the advantages and limitations of each service, and some low-level implementation details, so you can pick the right one and plan for long-term maintainability.
Management tools differences (coming soon)	Backend developers, data engineers, solution architects, and DevOps specialists.	Learn how to manage the full lifecycle of data services (from setup to automation) using the right tools for each task, and streamline operations by reducing manual work.
Retrieval and loading time differences (coming soon)	Client-side application developers working in both web and native SDKs.	Learn how different services behave when loaded, and how to optimize the performance so you can design faster, more responsive user experiences.
Visualization and interactivity differences (coming soon)	Client-side developers, UX/UI designers, technical leads, solution architects, technical product managers, and performance specialists.	Discover how to get the most out of these services to create the most user-friendly and powerful user interfaces possible.
Terms of use & pricing differences (coming soon)	Product managers, CTOs, and other decision makers.	Clarify when to use ArcGIS Online vs ArcGIS Location Platform based on pricing, quotas, and terms, so you can pick what works best for your needs.
Understand Service Usage Differences (coming soon)	FinOps, product managers, DevOps, and solution architects.	Connect usage patterns with actual costs to better prepare for forecasting expenses, planning budgets, and optimizing service configurations.

I hope this introduction has sparked your interest and left you eager to read the upcoming articles.

You’ve got several options to stay in the loop.

• Follow me here on dev.to
• Subscribing to the ArcGIS Blog RSS feed using your favorite reader.
• Follow me on social media (LinkedIn, Bluesky, or X). - Follow me on Medium.com (for the Spanish versions).

If anything was unclear, or if you think you’ve spotted an error or inconsistency in this article, I’d love to hear from you. You can write to me at [e-mail] to help improve the clarity and accuracy of this content.

Thank you to everyone who contributed to the content of this article. You rock! Extra special thanks to Rachael Ellen and Nico Loza.