ST_DISTANCE_VINCENTY

Compute the geodesic distance between two points on the WGS 84 ellipsoid using Vincenty's inverse formula.

Category: geospatialReturns: DOUBLEDialect: Standard

Syntax

ST_DISTANCE_VINCENTY(lat1, lng1, lat2, lng2)

Description

## Overview Returns the geodesic distance in meters between two points on the WGS 84 ellipsoid, using Vincenty's inverse formula. Vincenty models the Earth as an oblate spheroid (equatorial radius 6,378,137 meters, flattening 1/298.257223563) and solves iteratively for the shortest path between the two points. The result is accurate to within approximately 0.5 millimeter for almost all input pairs. Use ST_DISTANCE_VINCENTY when accuracy matters more than throughput: aviation routing, maritime navigation, cross-border surveying, legal boundary computations, and any analysis where the spherical approximation's roughly 0.3 percent error is unacceptable. ## When to use ST_DISTANCE_VINCENTY vs. alternatives - **ST_DISTANCE_VINCENTY** (this function): ellipsoidal (WGS 84), sub-millimeter accuracy. Slower and occasionally fails to converge for near-antipodal points. Use for survey-grade workloads. - **ST_DISTANCE_HAVERSINE**: spherical Haversine, accuracy about 0.3 percent. Much faster; the default for analytics, dashboards, and proximity filters. - **ST_DISTANCE_SPHERE**: spherical law of cosines; accuracy similar to Haversine but loses precision at very short distances. Prefer Haversine for general use. - **ST_DISTANCE**: planar distance in CRS units; use only on pre-projected data. ## Behavior - Returns a DOUBLE in meters. - Uses the WGS 84 reference ellipsoid (a = 6,378,137 m, f = 1/298.257223563). - Arguments are ordered (lat, lng), not (lng, lat). - Returns 0 for identical points. - Returns NULL if any argument is NULL. - Near-antipodal point pairs (diametrically opposite) can cause the iterative solver to fail to converge. Implementations typically return NULL or fall back to a spherical approximation in this case; wrap the call in COALESCE with ST_DISTANCE_HAVERSINE for robustness on adversarial inputs. - Handles the antimeridian correctly; longitudes do not need to be pre-normalized. - Inputs outside valid latitude/longitude ranges are not rejected; they produce numerically defined but geographically meaningless results. ## Accuracy and performance - Accuracy: roughly 0.5 mm for almost all inputs, degrading only for near-antipodes where the solver's convergence is marginal. - Performance: roughly 10 to 20 times slower than Haversine on a per-row basis because of the iterative solver. On multi-million-row joins the difference is meaningful; batch or pre-filter accordingly. - If you need Vincenty-grade accuracy for only a small fraction of your queries, project to a metric CRS once at ingest and use ST_DISTANCE on the projected values. ## Compatibility - Matches the classic Vincenty inverse formula used by standard geodesy libraries and land surveying tools. - Inputs are always WGS 84 decimal degrees. No SRID argument is required or accepted.

Parameters

Name	Type	Description
`lat1`		Specifies the WGS 84 latitude of the first point in decimal degrees, in the range -90 to 90.
`lng1`		Specifies the WGS 84 longitude of the first point in decimal degrees, in the range -180 to 180.
`lat2`		Specifies the WGS 84 latitude of the second point in decimal degrees, in the range -90 to 90.
`lng2`		Specifies the WGS 84 longitude of the second point in decimal degrees, in the range -180 to 180.

Examples

-- Ellipsoidal distance in meters.
-- Expected result: approximately 5,570,222 meters (5,570.2 km).
SELECT ST_DISTANCE_VINCENTY(51.5074, -0.1278, 40.7128, -74.0060) AS distance_m;

-- Divide by 1000 for kilometers.
SELECT ST_DISTANCE_VINCENTY(35.6762, 139.6503, 1.3521, 103.8198) / 1000.0 AS distance_km;

-- Vincenty accounts for Earth's flattening; Haversine does not.
SELECT
  ST_DISTANCE_VINCENTY(51.5074, -0.1278, 40.7128, -74.0060) AS vincenty_m,
  ST_DISTANCE_HAVERSINE(51.5074, -0.1278, 40.7128, -74.0060) AS haversine_m,
  ST_DISTANCE_VINCENTY(51.5074, -0.1278, 40.7128, -74.0060) -
    ST_DISTANCE_HAVERSINE(51.5074, -0.1278, 40.7128, -74.0060) AS delta_m;

-- Distance between two nearby Paris landmarks.
SELECT ST_DISTANCE_VINCENTY(48.8584, 2.2945, 48.8606, 2.3376) AS eiffel_to_louvre_m;

-- Vincenty keeps sub-meter accuracy even over hundreds of kilometers.
SELECT survey_id,
       ST_DISTANCE_VINCENTY(a_lat, a_lng, b_lat, b_lng) AS distance_m
FROM survey.catalog.measurements
ORDER BY distance_m DESC
LIMIT 100;

-- Vincenty can fail to converge for near-antipodal pairs; keep a fallback in critical paths.
SELECT
  route_id,
  COALESCE(
    ST_DISTANCE_VINCENTY(o_lat, o_lng, d_lat, d_lng),
    ST_DISTANCE_HAVERSINE(o_lat, o_lng, d_lat, d_lng)
  ) AS distance_m
FROM logistics.catalog.routes;

Pitfalls

Arguments are ordered (lat, lng), not (lng, lat). Reversing them silently produces wrong distances because latitude and longitude share overlapping numeric ranges.
Vincenty can fail to converge for near-antipodal point pairs (the two points are roughly on opposite sides of the Earth). Wrap critical calls in COALESCE with ST_DISTANCE_HAVERSINE to guarantee a non-NULL result.
The function is 10 to 20 times slower than ST_DISTANCE_HAVERSINE. Using it in a large radius filter when spherical accuracy would suffice wastes compute; pick the simpler function unless sub-meter accuracy is a requirement.
The result is in meters. Comparing against a kilometer or mile threshold without conversion silently filters out almost every row.
Vincenty uses WGS 84 parameters. Feeding coordinates from another datum (for example NAD27 or a regional grid) can introduce tens of meters of error even though the formula itself is highly accurate.