Satellite operators
You already have TLEs in PostgreSQL. Now your database can propagate them, predict passes, and screen for conjunctions without leaving SQL. Batch 12,000 observations in 17ms.
What is pg_orbit?
pg_orbit is a PostgreSQL extension that moves orbital mechanics computation inside your database. Instead of computing satellite positions in Python, planet coordinates in C++, or transfer orbits in MATLAB and then importing the results — the computation happens where your data already lives.
The “PostGIS for space” analogy
Section titled “The “PostGIS for space” analogy”PostGIS added spatial awareness to PostgreSQL — suddenly your database understood geometry, distance, and containment. pg_orbit does the same for celestial mechanics. Your database understands orbits, observation geometry, and the relationships between objects in the solar system. You can JOIN orbital computation results with any other table, filter with WHERE clauses, and let PostgreSQL’s query planner parallelize the work.
What it covers
Section titled “What it covers”| Domain | Theory | Key Functions | Accuracy |
|---|---|---|---|
| Satellites | SGP4/SDP4 (Brouwer, 1959) | observe(), predict_passes() | ~1 km (LEO, fresh TLE) |
| Planets | VSOP87 (Bretagnon, 1988) | planet_observe(), planet_heliocentric() | ~1 arcsecond |
| Sun | VSOP87 (Earth vector, inverted) | sun_observe() | ~1 arcsecond |
| Moon | ELP2000-82B (Chapront, 1988) | moon_observe() | ~10 arcseconds |
| Planetary moons | L1.2, TASS17, GUST86, MarsSat | galilean_observe(), etc. | ~1-10 arcseconds |
| Stars | J2000 catalog + precession | star_observe() | Limited by catalog |
| Comets/asteroids | Two-body Keplerian | kepler_propagate(), comet_observe() | Varies with eccentricity |
| Jupiter radio | Carr et al. (1983) sources | jupiter_burst_probability() | Empirical probability |
| Transfers | Lambert (Izzo, 2015) | lambert_transfer(), lambert_c3() | Ballistic two-body |
Who it’s for
Section titled “Who it’s for”Amateur astronomers & radio operators
Plan observation sessions entirely in SQL. “What planets are above 20 degrees tonight?” is a single query. Jupiter radio burst prediction replaces the Windows-only Radio Jupiter Pro.
Mission planning enthusiasts
Generate pork chop plots for interplanetary transfers as SQL CROSS JOINs. The Lambert solver handles 800,000 solutions per second. Compare transfer energies across launch windows without writing a line of Python.
What pg_orbit is NOT
Section titled “What pg_orbit is NOT”Not a GUI. pg_orbit returns numbers. Use Stellarium, GPredict, or STK for visualization. Use any plotting library to render its output.
Not sub-arcsecond. VSOP87 is accurate to about 1 arcsecond — sufficient for observation planning and visual astronomy, but not for dish pointing at GHz frequencies or precision astrometry. For that, use SPICE or Skyfield with DE441 ephemerides.
Not a TLE source. Bring your own TLEs from Space-Track, CelesTrak, or any other provider. pg_orbit parses and propagates them; it doesn’t fetch them.
Not a replacement for SPICE. No BSP kernel support, no light-time iteration, no aberration corrections at the IAU 2000A level. pg_orbit trades those last few milliarcseconds of accuracy for the ability to run computations at SQL speed, in parallel, joined with your other data.
Not a full mission design tool. The Lambert solver handles ballistic two-body transfers — no low-thrust trajectories, no gravity assists, no multi-body optimization. For full mission design, use GMAT or poliastro.