Nominatim

Open-source geocoding, honestly reviewed. No marketing copy, just what you actually get when you run it yourself.

TL;DR

• What it is: Open-source geocoder built on OpenStreetMap data — converts addresses to coordinates (forward geocoding) and coordinates to addresses (reverse geocoding), GPL-3.0 licensed, 4,154 GitHub stars [merged profile].
• Who it’s for: Developers and SaaS founders paying Google Maps API bills at volume. Not a beginner tool. Not something non-technical founders should attempt alone [5].
• Cost savings: Google Maps Geocoding API charges $5 per 1,000 requests after a $200/month free credit (~40,000 free requests). At 500,000 requests/month, that’s ~$2,300/month. Self-hosted Nominatim: $0 software cost, plus a beefy VPS [homepage].
• Key strength: Proven at scale — powers the official openstreetmap.org search box and serves 30 million queries per day on a single server [homepage]. The data is freely reusable and you own the infrastructure.
• Key weakness: The setup is genuinely hard. Importing a full planet database takes days and hundreds of gigabytes of storage. The public API is explicitly off-limits for production use. And OSM data quality in some regions is inconsistent [5][homepage].

---

What is Nominatim

Nominatim (Latin for “by name”) is a geocoding search engine built on OpenStreetMap data. You feed it an address — or a free-text query like “Cafe Paris, New York” — and it returns coordinates. You feed it coordinates and it returns the nearest address. That’s the whole pitch [homepage][README].

It’s the software that runs the search box on openstreetmap.org, which means it isn’t a prototype or a side project — it’s production software that handles real traffic at scale [homepage]. The latest release is 5.2.0, installable via pip from a Python virtualenv or built from the GitHub source [README].

What actually makes this worth reviewing isn’t the software itself — geocoding is a solved problem. The reason founders and developers end up looking at Nominatim is the billing. Google Maps API geocoding is free up to a point, then it isn’t. When you’re running a location-based SaaS with millions of monthly lookups, the API bill becomes one of your bigger line items. Nominatim is the standard answer to that problem, but it comes with real operational costs of its own that the official documentation undersells [5][1].

---

Why people choose it

The decision to self-host Nominatim is almost always a cost decision, occasionally a data sovereignty decision, and sometimes both.

The Google Maps billing problem. Google’s Geocoding API gives you $200/month in free credits — enough for roughly 40,000 requests at $5 per 1,000. Beyond that you pay. For a startup running address validation on user signups or a logistics tool batch-geocoding delivery routes, it’s easy to blow past that threshold. A GIS practitioner on Stack Exchange described saving 12,000 Euro per year (for 1,600 tracked assets over five years) by moving to self-hosted Nominatim, and noted that once the database is indexed, the per-query overhead is “very low in general” [1]. The savings compound every year you stay off the metered API.

Data ownership. When you route every geocoding request through Google or any third-party API, every address lookup, every user location, every delivery route leaves your infrastructure. One Stack Exchange responder framed it directly: “the independence you get” was worth the setup effort [1]. For a company handling sensitive location data — fleet management, medical deliveries, anything that touches addresses of real people — routing those through a third-party API is a risk you might not want to carry.

Scale proof. The public Nominatim instance at nominatim.openstreetmap.org handles 30 million queries per day on a single server [homepage]. That number settles the “but will it scale?” question. The software can handle production traffic. The question is whether you can handle running it.

Where the skepticism comes in. OpenCage, a managed geocoding service that runs Nominatim behind its own API, has a blunt take: the official OSM-hosted Nominatim is explicitly “not designed for production use” and their usage policy says as much [5]. Their framing is self-serving (they want you to pay them instead), but the underlying point about the public API is accurate — the usage policy really does prohibit high-volume production use. You either self-host, or you pay someone to host it for you. There’s no free lunch at scale.

---

Features

Based on the README, website, and how it’s actually used in third-party integrations:

Geocoding modes:

• Forward geocoding: free-text queries like “Cafe Paris, New York” or structured queries with explicit fields (postcode=12345, city=London, type=cafe) [homepage]
• Reverse geocoding: given any latitude/longitude, returns the nearest address or any OSM object given its ID [homepage]
• Language parameter support — you can request results in a specific language [2][3]

Data and freshness:

• Imports any OSM data file — from a single city extract to the full planet [README]
• Minutely updates available — OSM editors constantly improve the data, and Nominatim can pull those changes continuously [homepage]
• Configurable: you choose which OSM features to import, so you can slim down the database for a regional deployment [homepage]

Deployment flexibility:

• Python package (pip install) for the API and database components [README]
• Built-in web server via uvicorn + falcon for quick deployment [README]
• Scales from a laptop running city-level data to a multi-server setup for the full planet [homepage]

API surface:

• REST API that returns JSON, compatible with standard geocoding client libraries — Python’s geopy library has a Nominatim geocoder class that wraps the API directly [2][3]
• Works as a drop-in data source for map integrations via Leaflet.js, MapLibre GL JS, and Webflow custom code [4]

What it doesn’t do:

• No address formatting or annotation enrichment — you get coordinates and raw OSM attributes, not formatted strings, timezone data, confidence scores, or calling codes. OpenCage adds all of that on top of their Nominatim backend [5].
• No built-in UI — it’s an API, not an application. If you want a search box, you build it yourself [homepage].
• No managed hosting option — it’s self-host or find a third party [5].

---

Pricing: SaaS vs self-hosted math

Google Maps Geocoding (the benchmark):

• $200/month free credit = ~40,000 geocoding requests free
• $5 per 1,000 requests beyond that
• 100,000 requests/month: ~$300/month
• 500,000 requests/month: ~$2,300/month
• 2,000,000 requests/month: ~$9,800/month

Nominatim self-hosted:

• Software: $0 (GPL-3.0) [merged profile]
• VPS sizing depends entirely on your data scope:
  • City or regional extract: $20–40/month on Hetzner or Contabo, 4–8GB RAM, 100–200GB SSD
  • Full planet: you need a machine with 64GB+ RAM and 600GB+ fast SSD for reasonable query performance — budget $100–200/month or own the hardware
• Import time: days for the full planet, hours for regional extracts — this is not a one-time weekend project [README][5]

Managed Nominatim alternatives (for reference):

• Services like OpenCage or LocationIQ run Nominatim (and other geocoders) behind managed APIs with SLAs and formatted output — pricing varies, typically usage-based tiers. Data not available for direct comparison [5].

Concrete savings math for a mid-size use case:

Say your SaaS does 300,000 geocoding lookups per month — address validation on signups, location search, delivery routing. On Google Maps that’s (300,000 − 40,000) / 1,000 × $5 = $1,300/month, or about $15,600/year.

Self-hosting a regional Nominatim on a $40/month VPS: $480/year. That’s $15,000+ saved — enough to justify a week of engineering time to set it up properly.

The math only works if you stay in region. If your product needs global coverage, you need the full planet import, which means more expensive hardware and significantly more setup complexity [1][5].

---

Deployment reality check

This is the section that most Nominatim guides gloss over.

The planet file problem. The full OpenStreetMap planet file is large — tens of gigabytes compressed, and the Nominatim database after import is considerably larger. On fast hardware, a full-planet import takes anywhere from 24 hours to several days. During this time, the server is consumed by the import process. This isn’t an exaggeration or an edge case — it’s the documented reality [README][5].

The practical workaround that most developers use: start with a regional extract from Geofabrik (free downloads by country or continent). A country-level import is a few hours on modest hardware. If your product only operates in Germany, you don’t need the planet.

What you actually need:

• A Linux server (physical or VPS) — the bigger, the better for planet imports
• Python 3.x with pip [README]
• PostgreSQL with PostGIS extension (this is the database Nominatim runs on)
• The OSM data file for your target region [README]
• A reverse proxy (nginx, Caddy) if you want HTTPS on the API endpoint
• Optionally: scripts to automate minutely OSM updates if you need fresh data

Ongoing maintenance. The software and the geodata both change. OSM data isn’t a static file you import once — if accuracy matters, you need an update pipeline. The planet and regional extracts get updated regularly, and running minutely diffs requires an automated process [homepage][5]. OpenCage specifically calls out that “both the software and the geodata are changing continually and need to be kept up to date” as a reason to use their managed service instead [5].

The public API rate limits. If you’re testing the API at nominatim.openstreetmap.org before setting up your own instance, you’re subject to the OSM usage policy: maximum 1 request per second, no bulk geocoding, no commercial use [homepage]. The Python geocoding scripts that use geopy.geocoders.Nominatim reflect this reality — every example includes a time.sleep(1) between requests to stay within limits [2][3]. This is fine for experimenting; it’s a non-starter for production.

Realistic time estimates: Technical user with Linux server experience: 4–8 hours for a regional deployment including database setup, data import, and API verification. Full-planet deployment: plan for a dedicated weekend minimum, and have fallback capacity while the import runs. Non-technical founder: this is not a solo project — you need someone who has deployed PostgreSQL in production before.

---

Pros and cons

Pros

• Zero API costs at scale. Once running, every query is free. No per-request billing, no monthly caps, no surprise invoices [homepage][1].
• Proven at 30M queries/day. Not a toy — the same software that powers the official OSM site at full global scale [homepage].
• Data sovereignty. Every geocoding request stays inside your infrastructure. No third-party sees your users’ addresses [1].
• OSM data is freely reusable. Unlike proprietary map data (Google, HERE, TomTom), you can store, redistribute, and transform OSM-derived results within the license terms [5].
• Regional installs are practical. You don’t need the full planet. A country or city extract installs in hours and covers most use cases [README][1].
• Active development. Version 5.2.0 is current, CI testing via GitHub Actions, and major geocoding services (including OpenCage, whose CTO is a top-two code contributor) invest in it [5][README].
• Python-native. Pip install, Python API, geopy compatibility — fits standard data engineering stacks with no friction [README][2].

Cons

• Full-planet setup is genuinely hard. Multi-day imports, 600GB+ storage, 64GB+ RAM for comfortable query performance. If you need global coverage, the infrastructure cost is non-trivial [5][README].
• No managed option. There’s no Nominatim Cloud. You either run it yourself or you’re using a third-party wrapper [homepage][5].
• The public API is not for production. Usage policy explicitly prohibits high-volume or commercial use. Rate-limited to 1 request/second [homepage].
• No result enrichment. Raw geocoding output — no timezone, no confidence score, no formatted address strings. Building those yourself takes effort [5].
• OSM data quality varies. In well-mapped areas (Western Europe, North America), results are excellent. In less-covered regions, expect gaps and errors that you can’t fix by switching data sources [1].
• No UI. It’s a pure API. Any user-facing interface is your job to build [homepage].
• Ongoing maintenance burden. Update pipelines, software upgrades, database tuning — it doesn’t run itself [5].

---

Who should use this / who shouldn’t

Use Nominatim if:

• You’re a developer or engineering team paying $500+/month in Google Maps geocoding API bills and you want to eliminate that line item.
• Your application operates in a well-covered OSM region and you can scope your import to that region.
• You have someone on the team who has operated PostgreSQL in production — this is the actual prerequisite, not Linux comfort.
• Data sovereignty matters — you can’t route user addresses through third-party APIs due to compliance or client contracts.
• You’re building something location-heavy (fleet management, logistics, real estate) where geocoding is a core infrastructure component, not a nice-to-have.

Use a managed Nominatim service (OpenCage, LocationIQ, etc.) instead if:

• You want the OSM-based geocoding quality without the operational burden.
• Your volume is moderate (tens of thousands of requests per month) and the managed service pricing is less than your engineering time to maintain self-hosted.
• You need formatted addresses, confidence scores, timezone annotations, or other enrichment on top of raw geocoding [5].

Stay on Google Maps Geocoding if:

• Your monthly bill is under $200 (you’re in the free tier anyway).
• You need the absolute highest global data quality — Google’s proprietary dataset still wins in sparse regions.
• You have no one on the team with database operations experience.
• You need premium features like Places API, Autocomplete, or Street View alongside geocoding.

Skip it entirely if:

• You’re a non-technical founder who wants “map functionality” as a feature — use a hosted service or a Webflow plugin [4].
• Your use case is a contact page map embed — just use an OpenStreetMap iframe [4].

---

Alternatives worth considering

• OpenCage — Managed geocoding API that runs Nominatim (and other geocoders) behind it. Adds formatted addresses, timezone data, confidence scores. Backed by OpenStreetMap Foundation corporate members who actively contribute to Nominatim development. Good middle ground between self-hosted and Google [5].
• LocationIQ — Another managed geocoding API built on OSM data; listed as a Nominatim supporter [homepage]. Offers free and paid tiers.
• Pelias — Open-source geocoder, also built on OSM and other open datasets, with a different architecture designed for microservices deployment. More flexible but also more complex.
• Photon — Open-source geocoder from Komoot (also a Nominatim supporter [homepage]) focused on fast type-ahead search. Easier to deploy than Nominatim for simple search-box use cases.
• Google Maps Geocoding API — The incumbent. Best data quality globally, easiest integration, most expensive at scale. The bill that sends people to Nominatim in the first place.
• HERE Geocoding API — Alternative to Google with competitive data quality, more enterprise-friendly pricing tiers.
• Mapbox Geocoding — Well-designed API with decent free tier, developer-friendly, proprietary data with OSM supplementation.

The realistic shortlist for a developer who wants to eliminate API bills: Nominatim self-hosted (maximum savings, maximum ops burden) or OpenCage/LocationIQ (moderate savings, zero ops burden). The choice comes down to whether your engineering time is better spent on infrastructure or product.

---

Bottom line

Nominatim is the right answer to Google Maps API bills for engineering teams that can handle the operational reality. The software itself is solid — it’s production-tested at 30 million queries per day, actively maintained, and the OSM data it runs on is freely usable. The catch is that “self-hosted geocoding” involves a genuine infrastructure project: a large PostgreSQL database, a substantial import process, and an ongoing update pipeline that doesn’t run on autopilot. For a regional deployment where you’ve scoped the data to a country or continent, a competent backend developer can get this running in a day. For full-planet coverage, you’re looking at dedicated hardware, days of import time, and a real ops commitment.

If that trade-off works for you — and for high-volume location applications, the math usually does work — Nominatim is what you want. If you want the cost benefits of OSM-based geocoding without running the database yourself, a managed service like OpenCage is the more honest recommendation. If you’re a non-technical founder who stumbled here while looking for a map embed: this isn’t what you’re looking for.

---

Sources

1. GIS Stack Exchange — “Seeking hosted nominatim services” (asked 2013, modified 2021). https://gis.stackexchange.com/questions/48274/seeking-hosted-nominatim-services
2. Gary Sieling — “Python geocoding examples with Nominatim”. https://www.garysieling.com/blog/examples/python/
3. Gary Sieling — “Mapping examples with Nominatim”. https://www.garysieling.com/blog/examples/mapping/
4. Webflow — “Integrate OpenStreetMap with Webflow | Quick connect guide”. https://webflow.com/integrations/openstreetmap
5. OpenCage — “Looking for alternatives to self-hosting Nominatim? Try OpenCage.” https://opencagedata.com/alternatives/self-hosting-nominatim

Primary sources:

• GitHub repository and README: https://github.com/osm-search/nominatim (4,154 stars, GPL-3.0 license)
• Official website: https://nominatim.org
• Installation documentation: https://nominatim.org/release-docs/latest/admin/Installation