Buying postal data across several countries looks simple until the files arrive.
A procurement list may use one phrase—“postal code database”—for products that are fundamentally different. One country may have precise small-area codes. Another may use codes that identify delivery routes, buildings or post-office service areas. One supplier may deliver polygons; another may provide points or reference tables. Update frequency, permitted uses and geographic completeness can vary just as widely.
The right evaluation therefore starts with the business decision the data must support. A routing application, fraud model, territory plan and map visualization do not need the same geometry or the same level of precision.
Why Postal Data Is Not Uniform Across Countries
Postal systems were designed for mail delivery, not as a single global geography standard. Their structures reflect local addressing practices, postal operations and national data policies.
In the United States, ZIP Codes are operational delivery constructs. The U.S. Census Bureau creates ZIP Code Tabulation Areas, or ZCTAs, as statistical approximations built from Census geography. A ZCTA can be useful for analysis, but it should not automatically be described as an official USPS ZIP Code boundary.
The United Kingdom has a different hierarchy and a well-established official geospatial ecosystem. Ordnance Survey’s Code-Point Polygons product, for example, provides polygons associated with postcode units under its own specifications and licensing terms.
Canada introduces another set of considerations. Six-character postal codes can represent compact urban locations or much broader rural delivery areas. Open address sources are increasingly useful, including Statistics Canada’s Open Database of Addresses, but an enterprise deployment may still require national schema harmonization, documented refreshes, licence review and support.
These differences are not defects. They are the reason a global product should be evaluated country by country rather than by one headline record count.
Eight Criteria for Comparing International Postal Data
1. Geographic coverage
Ask for a country-level coverage matrix, not just a total number of countries. It should identify the postal-code levels included, known exclusions and the date each country was last refreshed.
“Global” can mean very different things. A product may cover national-level codes broadly while offering detailed geometry in only a subset of markets. The matrix should make that distinction visible.
2. Geometry type
Confirm what each row represents. Is it a polygon, delivery point, centroid, address range or textual reference record? If polygons are derived, ask how they were constructed and validated.
A map can make a point buffer look like a boundary. That does not make the two products analytically equivalent.
3. Resolution and hierarchy
Determine whether the dataset contains the level needed for the use case: national codes, outward codes, sectors, five-digit ZIP Codes, ZIP+4 references, Canadian FSAs, six-character postal codes or another local level.
More detail is not always better. A territory-planning model may perform well with stable regional polygons, while last-mile operations may need address-level precision.
4. Data vintage and update process
A credible provider should state when a country was updated and how changes are detected, reviewed and released. Ask whether updates are scheduled, event-driven or dependent on source availability.
A generic promise such as “updated regularly” is difficult to operationalize. Procurement and data engineering teams need dates, version identifiers and a change-log process.
5. Attribute schema
Review the fields as carefully as the geometry. Useful attributes may include the postal code, hierarchy, locality, administrative areas, country codes, source/version information and quality indicators.
For multi-country work, consistency matters. The ideal schema preserves meaningful local detail while also providing normalized fields that can be used across markets.
6. Delivery and integration
Confirm available formats, coordinate reference systems, compression, file partitioning and delivery channels. Common requirements include GeoPackage, Shapefile, GeoJSON, CSV, Parquet, database delivery, cloud marketplace access and APIs.
Large polygon products should also be tested in the target platform. A technically valid file may still be awkward to load, query or update in production.
7. Quality and limitations
No postal dataset is perfect. Strong documentation identifies edge cases: non-geographic codes, post-office boxes, shared codes, seasonal changes, sparse rural coverage, generalized boundaries and areas where only points are available.
Limitations do not necessarily disqualify a product. Undocumented limitations do.
8. Licensing and permitted use
Confirm whether the licence permits internal analytics, customer-facing maps, derived products, address validation, redistribution, API responses and use by affiliates or contractors.
Also clarify retention rights when a subscription ends, attribution requirements, territorial restrictions and whether source-specific conditions apply in individual countries.
Points, Centroids and Polygons Are Not Interchangeable
A postal code may be represented as text in an address table, a point placed near its centre, a point tied to a delivery location or a polygon intended to approximate its service area. Each representation answers a different question.
Points work well for proximity, labeling and some routing tasks. Polygons support area-based joins, territory summaries and thematic mapping. Address records are necessary when the objective is to validate or locate individual premises.
Before comparing vendors, write down the spatial operation the application must perform. If the requirement is “assign every customer record to a sales area,” test the actual spatial join. If the requirement is “display the approximate location of a code,” a centroid may be sufficient and easier to operate.
Licensing Questions to Resolve Before a Pilot
Licensing should be examined before engineering invests in a proof of concept.
Ask whether the pilot data can be used with real internal records. Confirm who may access it, where it may be hosted and whether screenshots or derived statistics can be shared with decision-makers. If the final product will expose postal information to customers, make that use explicit.
For products assembled from several national sources, request a clear explanation of how the commercial licence relates to underlying source conditions. The goal is not to demand identical rights everywhere. It is to understand the differences before launch.
How to Design a Useful Data Evaluation
A useful evaluation is small enough to complete quickly and realistic enough to reveal production problems.
Choose two or three representative markets. Include one dense urban area, one rural or remote area and, where relevant, a country with a different postal hierarchy. Supply test cases that reflect the intended workflow.
Measure:
- match or assignment rate;
- missing and duplicate codes;
- geometry validity;
- unexplained gaps or overlaps;
- agreement with known reference locations;
- load and query performance;
- schema consistency;
- clarity of documentation; and
- time required to integrate an update.
Record the product version and evaluation date. Postal data changes, so results without a version are hard to reproduce.
Questions to Ask Every Provider
A short, consistent questionnaire makes comparisons more useful:
- Which postal levels are included in each target country?
- What does each geometry represent?
- When was each country last updated?
- Which areas or code types are excluded?
- How are changes detected and quality checked?
- Which formats and delivery methods are available?
- Can the provider supply a schema and representative sample?
- What uses, displays and derived products does the licence permit?
- Are any source-specific restrictions passed through?
- What support is available during evaluation and production updates?
Build a Dataset That Fits the Decision
The best international postal code database is not necessarily the one with the largest headline count. It is the one whose coverage, geometry, update process, schema and licence fit the decisions your organization needs to make.
Aeroview provides postal boundary and location datasets for enterprise GIS, analytics and location-intelligence workflows. We can help teams compare country coverage, select the appropriate postal level and evaluate representative data before a broader rollout.
Request a country-coverage review or sample: https://aeroview.ca/contact/
