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_orrery?
An orrery is a clockwork model of the solar system — brass gears turning planets in their courses. pg_orrery is the same idea, built from Keplerian parameters and SQL instead of wheelwork. Where a mechanical orrery approximates orbits with gear ratios, a database orrery computes them from the six orbital elements that define each trajectory.
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_orrery 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 |
| DE ephemeris (optional) | JPL DE440/441 | planet_observe_de(), moon_observe_de() | ~0.1 milliarcsecond |
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_orrery is NOT
Section titled “What pg_orrery is NOT”Not a GUI. pg_orrery returns numbers. Use Stellarium, GPredict, or STK for visualization. Use any plotting library to render its output.
Not sub-arcsecond by default. The built-in VSOP87 pipeline is accurate to about 1 arcsecond — sufficient for observation planning and visual astronomy. For precision work (dish pointing, occultation timing, astrometry), pg_orrery v0.3.0 supports optional JPL DE440/441 ephemeris files that bring accuracy to ~0.1 milliarcsecond. DE is opt-in and requires a one-time GUC configuration.
Not a TLE source. Bring your own TLEs from Space-Track, CelesTrak, or any other provider. pg_orrery 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. With DE enabled, pg_orrery matches SPICE on raw planet position accuracy — the remaining gap is in apparent-position corrections (aberration, light-time, nutation) that matter for sub-arcsecond apparent coordinates.
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.