OpenStreetMap

Open-source mapping data, honestly reviewed. No marketing fluff — just what you get when you try to replace Google Maps with it.

TL;DR

• What it is: A free, community-built geospatial database covering the entire planet — map data, not a map application. Think Wikipedia, but for geography [4].
• Who it’s for: Developers and founders paying non-trivial Google Maps API bills who want to own their map stack, plus humanitarian and research teams that need unrestricted geodata [4].
• Cost savings: Google Maps JavaScript API costs $7 per 1,000 requests after the free monthly credit; geocoding runs $5 per 1,000 requests. A maps-heavy startup can hit $500–$2,000/mo before noticing. OSM data is free. Running it yourself costs hardware and time [4].
• Key strength: The data itself is extraordinary — 10.5 million registered users, 9.1 billion nodes, 4 million edits per day, used by Facebook, Uber, and Microsoft [4]. The coverage and freshness rival or beat commercial alternatives in most regions.
• Key weakness: OSM is a database, not a ready-to-run service. Replacing Google Maps means assembling three separate systems: a tile server, a routing engine, and a geocoder. For the full planet, the hardware requirements alone ($1,600+ in RAM and storage) put this out of reach for most founders who don’t have a spare server room [1].

---

What is OpenStreetMap

OpenStreetMap is a global geospatial database built and maintained by volunteers. Anyone can add a road, a café, a hiking trail, or a bus stop. The data is free to use under an open license (ODbL — the Open Database License), meaning you can build commercial products on it, as long as you attribute and share derived datasets under the same terms [4].

The GitHub repository listed here (2,663 stars) is the Rails application that runs the openstreetmap.org website — user accounts, the map editor, diary entries, GPX uploads, and the editing API. That’s not the thing you’d self-host to replace Google Maps. It’s the administrative shell around the data.

What most developers actually mean when they say “self-hosting OSM” is standing up three separate services [1][5]:

• A tile server — renders or serves the visual map tiles your users see
• A routing engine — calculates routes from A to B (Valhalla, OSRM, or GraphHopper)
• A geocoder — converts addresses to coordinates and vice versa (Nominatim)

These three services are separate open-source projects, each with its own installation, its own data pipeline, and its own hardware demands. OSM is the common data source all three consume.

The distinction matters because self-hosting OSM is not like self-hosting Nextcloud or Gitea. There’s no single Docker image you pull and run. It’s infrastructure work, measured in days, not hours.

---

Why people choose it

The reasons people end up here are consistent across every article in this review [1][2][4][5].

Google Maps API pricing gets punitive at scale. The $200/month free credit sounds generous until you realize that $200 buys you roughly 28,000 map tile loads. A mid-traffic web app with a map on every listing page can blow through that credit in a week. Once you’re past the free tier, the meter runs fast and there’s no cap — just a bill that grows with your success [4].

Google Maps data isn’t yours. You cannot download it, analyze it, or build derived datasets. If Google changes pricing or APIs (which it has, multiple times), you migrate on their schedule. With OSM, the data is local. No API key to revoke, no rate limit to hit, no vendor to negotiate with [4].

Privacy and data sovereignty. Every time a user loads a Google Maps embed, that request hits Google’s servers and logs the user’s location. Self-hosted maps don’t. For apps in healthcare, legal tech, or anything touching GDPR-sensitive geolocation, that matters [1][2].

The data is genuinely good. It used to be fair to say Google Maps had better coverage. That’s less true now. OSM contributors have mapped things Google’s satellite passes miss: footpaths, interior building layouts, disaster zones after earthquakes. The 2010 Haiti response — where OSM volunteers mapped emergency infrastructure faster than any commercial provider — is the canonical example [4]. For non-urban areas in Europe and for specialized mapping (bike paths, wheelchair accessibility, hiking trails), OSM often beats Google.

The light-path story has gotten better. Article [2] describes a workflow using ProtoMaps and PMTiles that dramatically lowers the barrier: download a regional extract from Geofabrik, convert to a single PMTiles file using Tilemaker, serve it from a static file host with HTTP range requests, and render with MapLibre. No database. No tile-rendering daemon. Colorado processes in under a minute. The whole setup can live on a cheap CDN. For founders who need maps but not routing or geocoding, this is now a realistic Saturday-afternoon project [2].

---

Features

OpenStreetMap is data infrastructure, not a feature list. But the ecosystem it enables covers everything Google Maps does:

Map rendering:

• Pre-rendered raster tiles (PNG) via standard tile servers like Tirex or Renderd + Mapnik [1][5]
• Vector tiles (PMTiles, MBTiles) via Tilemaker — modern, dynamically styleable, lighter to serve [2]
• Multiple rendering styles: the default OSM “carto” style, Mapbox GL styles, custom Lua configs [2][5]

Routing:

• Valhalla — supports car, bike, pedestrian, transit; handles turn restrictions and live traffic [1]
• OSRM — faster for simple car routing, less flexible [1]
• GraphHopper — Java-based, good for cycling-specific profiles [1]

Geocoding:

• Nominatim — the standard OSM geocoder; converts addresses to coordinates and supports reverse geocoding [1][5]
• Photon — an alternative based on Elasticsearch, faster for autocomplete [5]

Data access:

• Full planet dump available at planet.openstreetmap.org (currently ~66GB compressed) [1]
• Regional extracts via Geofabrik (by country or continent) — the sane starting point [1][2]
• OSM’s own editing API (v0.6) for reading and writing map elements [README]
• Overpass API for complex geospatial queries without running your own database

Front-end:

• Leaflet.js is the standard lightweight web client for raster tiles [3]
• MapLibre GL is the modern choice for vector tiles — free, open-source, and actively maintained [2]

---

Pricing: SaaS vs self-hosted math

OSM data has no license fee. The cost is entirely infrastructure.

Google Maps API for comparison (the thing you’re escaping):

• Maps JavaScript API: $7 per 1,000 map loads after $200/mo free credit
• Geocoding: $5 per 1,000 requests
• Routes: $5–10 per 1,000 requests
• A moderately busy app at 100,000 map loads/month: ~$500/mo after the credit
• Heavy usage (500K loads/month): $3,300/mo. Data not invented — calculated from published Google pricing [4].

Mapbox (an OSM-based commercial service, easier than self-hosting):

• Free tier: 50,000 map loads/month
• Pay-as-you-go past that: $0.50 per 1,000 loads (much cheaper than Google)
• Geocoding: $0.75 per 1,000 requests

Self-hosted OSM — full planet stack (from article [1]):

• Hardware minimum for full planet: 128GB RAM, 1TB+ NVMe SSD (upgraded from 32GB RAM for ~$400 in RAM alone)
• Storage for North America only: ~667GB (tile data + routing + geocoding combined)
• Estimated storage for full planet: ~3.7TB [1]
• VPS equivalent: a server with those specs costs $150–$300/mo on Hetzner or Contabo
• Import time: days for the full planet. The author of [1] couldn’t successfully import the full planet at all and fell back to North America only.

Self-hosted OSM — regional extract, PMTiles approach (from article [2]):

• No database required — one .pmtiles file per region
• Colorado extract: processed in under a minute on a consumer laptop
• Hosting: a static file host or CDN — $1–5/mo for regional coverage
• Front-end rendering: MapLibre GL, free
• Trade-off: no server-side routing or geocoding; those are separate problems

Concrete math for a typical non-technical founder:

If you have a map-heavy app doing 200,000 map tile loads/month and 20,000 geocoding requests: Google Maps API ≈ $1,100/mo. Mapbox ≈ $90/mo. Self-hosted regional PMTiles stack ≈ $5/mo for storage + your setup time. Self-hosted full-planet stack ≈ $200–300/mo for a capable VPS.

The PMTiles approach only wins if you don’t need routing or live geocoding. The moment you add those, you’re back to needing serious infrastructure — and the economics shift toward a managed OSM-based service like Geoapify or Stadia Maps rather than running it yourself.

---

Deployment reality check

Every article that covers OSM self-hosting repeats the same warning: the hardware requirements are not proportional to the server size you’re used to [1][3][5].

The full-planet path (article [1]): The author — an experienced developer with a gaming PC — upgraded to 128GB of RAM specifically for this project. Even then, the full planet import failed repeatedly, and the project was scaled back to North America only. The resulting stack used 667GB of disk across three services. If you want global coverage, you’re looking at 3–4TB of storage and RAM measured in hundreds of gigabytes.

Import time for a tile server on a single region can run multiple days. Nominatim’s full-planet import takes 2–3 days on fast hardware. This is not a “deploy and forget” operation — it’s infrastructure that needs ongoing updates as OSM data changes [5].

The regional/PMTiles path (article [2]): Dramatically more approachable. The toolchain is: download a Geofabrik extract (pick a country or state), run Tilemaker to produce a .pmtiles file, upload to any static host or CDN, wire up MapLibre GL on the front end. A technically literate developer can do this in an afternoon. A non-technical founder following a guide: probably a weekend plus someone who can write a few lines of JavaScript.

What you get: a beautiful, styleable, fast map with no ongoing per-request cost. What you don’t get: routing, geocoding, or search. You’d still need to call Nominatim (either self-hosted or via a free/paid third-party) for address lookup.

What can go wrong (from the articles):

• The full-planet import will likely crash at least once before succeeding. Patience required [1].
• Keeping data fresh requires periodic re-imports or incremental update pipelines — not set-and-forget [5].
• The routing engines (Valhalla, OSRM) each require their own data preparation step on top of the OSM data [1].
• Vector tile styling with MapLibre requires either learning the style JSON spec or using a visual editor like Maputnik [2][5].
• The article [5] describes this bluntly: “it’s a lesson in patience, problem-solving, and iterative learning” — not a flattering framing, but an accurate one.

Realistic time estimates: full-planet stack for an experienced sysadmin: 1–2 weeks including hardware setup, imports, and tuning. Regional PMTiles stack for a developer: 4–8 hours. For a non-technical founder with no server experience: the full-planet path is genuinely not recommended without help.

---

Pros and cons

Pros

• The data is free, forever. ODbL is a real open license. No API key, no rate limit, no vendor negotiation. The data belongs to the community [4].
• Coverage and freshness rival commercial alternatives in most regions. Over 9.1 billion nodes, updated by 1.75 million active contributors, 4 million edits per day [4]. Local details that commercial providers miss are often in OSM first.
• Used by serious players. Facebook, Uber, Microsoft, and Apple (partially) build on OSM data. If it’s good enough for Uber’s routing engine, it’s good enough for your app [4].
• Multiple deployment profiles. From “upload one file to a CDN” (PMTiles) to “run the full planet stack” (tile server + Valhalla + Nominatim). You can match the approach to your actual requirements [1][2].
• No vendor lock-in. The data is a standard format (PBF, GeoJSON, Shapefile). Switch tile servers, switch routing engines, switch style libraries — the underlying data is portable.
• Privacy by design. Self-hosted maps don’t phone home. No third-party tracking your users’ map requests [1][2].
• Active community. Real humans on the OSM Community Forum, mailing lists, IRC. The mapping community is genuinely engaged [3].

Cons

• Not a single thing you install. Three separate systems (tile server, routing, geocoder), each with their own data pipeline. There is no “OSM in a box” [1][5].
• Hardware demands are brutal for full-planet coverage. 128GB RAM and 3–4TB storage are real requirements, not conservative estimates [1]. A $6 VPS doesn’t cut it.
• Import times are measured in days, not minutes. Initial setup of Nominatim or a tile server for large regions is a multi-day process on fast hardware [5].
• Keeping data fresh requires operational work. OSM data changes constantly. Staying current means running update pipelines, not just re-deploying a container [5].
• The easy path (PMTiles) doesn’t include routing or geocoding. You’ll still need external services for those, which reintroduces per-request costs [2].
• Styling is a skill. Getting maps that look polished requires learning MapLibre style JSON or paying for a pre-built style. The default OSM “carto” style is functional, not beautiful [2][5].
• No commercial support. OSM is a foundation and a community, not a vendor. If something breaks in production, the community forum is your support tier [3].

---

Who should use this / who shouldn’t

Use OSM if:

• You’re paying Google Maps or Mapbox $500+/mo and your use case is primarily displaying maps (not complex routing).
• You have at least one developer who can spend a week on infrastructure, or budget to hire someone to set it up.
• You need geographic data for analysis, not just display — OSM’s raw data is downloadable and queryable in ways Google’s never will be.
• Privacy or data sovereignty is a requirement (healthcare, legal, GDPR).
• You’re building on a specific region (one country, one city) — the hardware story becomes tractable at smaller scope [1][2].

Use the PMTiles/Protomaps path specifically if:

• You need maps displayed in your app but don’t need server-side routing or geocoding.
• You want to eliminate per-request billing entirely.
• You’re comfortable with JavaScript and can wire up MapLibre GL [2].

Use a managed OSM-based service (Geoapify, Stadia Maps, Maptiler) instead if:

• You want OSM data without the infrastructure burden.
• You need routing and geocoding alongside tiles.
• Your budget is $20–100/mo rather than $500+/mo on Google Maps — these services are dramatically cheaper than Google while requiring zero self-hosting [4].

Stay on Google Maps / Mapbox if:

• Your map usage is light enough to stay within Google’s $200/mo free credit.
• You have no developer capacity to spend on infrastructure.
• You need features like Google’s real-time traffic, Street View, or business listings — OSM doesn’t have those.
• Reliability guarantees and SLA matter and you can’t absorb downtime from a self-managed stack.

Don’t attempt full-planet self-hosting if:

• You don’t have dedicated hardware or a large VPS budget.
• You need global routing and geocoding from day one.
• Your team has never run a PostgreSQL database with PostGIS extensions [1][5].

---

Alternatives worth considering

• Geoapify — managed OSM-based service offering tiles, geocoding, routing, and place search. Free tier for development; paid plans start around $50/mo. The sensible middle path between Google Maps and full self-hosting [4].
• Maptiler — similar managed OSM offering with high-quality vector tiles and styles. Good design defaults out of the box.
• Stadia Maps — another managed OSM tile provider. Competitive pricing, solid uptime.
• Protomaps / PMTiles — the serverless self-hosting approach described in [2]. Use Geofabrik extracts + Tilemaker + MapLibre. Best for display-only maps where you don’t need server-side routing.
• Mapbox — OSM-based but commercial. Much cheaper than Google Maps at scale ($0.50 per 1,000 loads vs $7). The hosted product with the best design tooling in the category.
• HERE Maps — commercial, not OSM-based. Comparable to Google in features and pricing. Relevant if you need automotive-grade routing data.
• Leaflet.js + OSM tiles (just use openstreetmap.org tiles) — technically possible for low-traffic personal projects. OSM’s usage policy explicitly discourages heavy reliance on their free tile servers. Fine for a side project, not for production [3].

---

Bottom line

OpenStreetMap is one of the most remarkable community projects in software — 20 years of global volunteers building a geospatial database that tech giants depend on. But it’s not a SaaS replacement you self-host on a weekend. It’s a data layer that requires you to assemble your own stack: tile server, routing engine, geocoder, and the hardware to run them.

For founders escaping Google Maps API bills, the honest advice is: start with a managed OSM-based service (Geoapify, Maptiler) rather than self-hosting. You get the cost savings — 80–90% cheaper than Google — without the infrastructure burden. Self-hosting makes sense when you’ve outgrown managed services, need guaranteed data sovereignty, or have specific coverage requirements that managed providers don’t meet.

If you do want to self-host: scope it to a region rather than the full planet, use the PMTiles approach if you only need display (not routing), and treat the first week as infrastructure work, not product work. The data is genuinely excellent — the effort is in the plumbing.

If the plumbing is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients. One-time setup, you own the infrastructure, the Google Maps bill disappears.

---

Sources

1. wcedmisten.fyi — “Self Hosting a Google Maps Alternative with OpenStreetMap” (November 20, 2022). https://wcedmisten.fyi/post/self-hosting-osm/
2. Aaron Blondeau, DEV Community — “Self hosted maps for (practically) free”. https://dev.to/aaronblondeau/self-hosted-maps-for-practically-free-1i3n
3. OpenStreetMap Community Forum — “OSM, Self-Hosted where to start?” (December 2012). https://community.openstreetmap.org/t/osm-self-hosted-where-to-start/62184
4. Geoapify — “What is OpenStreetMap and Why It Might Be Better than Google Maps”. https://www.geoapify.com/what-is-openstreetmap-and-how-it-is-better-than-google-maps/
5. Sven Reifschneider, R-Digital Blog — “Map Mastery: My Journey to Building an OpenStreetMap Server” (September 9, 2024). https://reifschneider.digital/blog/map-mastery-openstreetmap-server

Primary sources:

• GitHub repository: https://github.com/openstreetmap/openstreetmap-website (2,663 stars, GPL-2.0)
• Official website: https://www.openstreetmap.org
• About page: https://www.openstreetmap.org/about
• Copyright and license: https://www.openstreetmap.org/copyright