The difficulty depends on what size of market you're trying to serve at what reliability target with geographic constraints, how often you want to update your d

The difficulty depends on what size of market you're trying to serve at what reliability target with geographic constraints, how often you want to update your data, and how many map tiles / second you want to serve. Consider a few different scenarios: 1. If you're trying to serve a single website and map style, with limited traffic in one region, this fairly easily accomplished using a single map tile server using one of the established methods (something like 8 cores, 32GB of RAM, and a few hundred GBs of disk will get you most of the way there). The difficulty is mostly determine how you want to set it up and then provisioning the server to do it. This process will probably take you a few days. Updates will be infrequent, map data will be stale, and speed will be tolerable in your targeted geographic region. 2. Let's say you take a step up. You need to serve global traffic with one style, but only a few requests / second. You can still do this via a single tile server, but now you need a CDN to make it fast. Cache misses will be slow since it has to render and then send the tile to the CDN (up to 500ms of latency due to geographic constraints and cache fill times). 3. Let's say you now need multiple styles, global traffic, 10s of tile requests / second, and good reliabilty. Now you need to distribute your servers, so you'll probably need three or four servers of at least the above mentioned specs, you need to keep them in sync. 4. Now let's say you need multiple styles, global traffic, and up-to-date data. You'll need to keep the OSM data stored locally so you can update it (minimum 500GB in Postgres + PostGIS). You need to distribute this all around the world. You need to handle updates, but do them in sync. All of these are short of actually offering a commercial service for multiple companies, since in that case you need a global service structure, a CDN that's pretty efficient, enough tile servers to handle spikes in demand (pretty common in map tile services), and probably a couple layers of cache to keep everything moving smoothly. There are a few projects that make this easier. For instance, openmaptiles.org is what our solution was modeled after (and we still use their schema, mostly unchanged), but in the end it's hard because it's a lot of data, that requires a lot of compute (either up-front or at a moments notice) to be responsive, and requires a lot of orchestration to keep it all well-oiled.