No Clocks

The obvious and more well known SQL way to keep some transient state is via temp tables! They give some nice data type guarantees, performance, editor happiness to name a few benefits. But - don’t use them for high frequency use cases! A few temp tables per second might already be too much and a disaster might be waiting to happen…Because CREATE TEMP TABLE actually writes into system catalogs behind the scenes, which might not be directly obvious… And in cases of violent mis-use - think frequent, short-lived temp tables with a lot of columns, plus unoptimized and overloaded Autovacuum together with long-running queries - can lead to extreme catalog bloat (mostly on pg_attribute) and unnecessary IO for each session start / relcache filling / query planning. And it’s also hard to recover from without some full locking - so that for critical high velocity DB’s it might be a good idea to revoke temp table privileges altogether - for app / mortal users at least (not possible for superusers).

The 2nd most obvious way to keep some DB-side session state around would probably be to use more persistent normal tables, right? Already better than temp tables as no danger of bloating the system catalog, right? NO. Pushing transient data though WAL (including replicas and backup systems) is pretty bad and pointless and only to be recommended for tiny use cases. In the Postgres world, exactly for these kinds of transient use cases, special UNLOGGED tables should be used! Which can relieve the IO pressure on the system / whole cluster considerably. One of course just needs to account for the semi-persistent nature - and the fact that they won’t be private anymore. Meaning usage of RLS in case of secret data or just using some random enough keys to avoid collisions.

Geospatial APIs are software abstraction layers that provide standardized methods to query, analyze, and visualize spatial data from diverse sources. They support essential functionalities including 2D/3D map rendering, geocoding, coordinate transforms, and real-time sensor data integration. Modern designs employ RESTful architectures and OGC standards to enhance interoperability, performance, and scalability across geospatial applications.

A geospatial Application Programming Interface (API) is a software abstraction layer—typically a web service or client library—that exposes standardized operations for querying, rendering, analyzing, and modeling spatial data, including vector features, raster coverages, multi-dimensional sensor observations, and geospatial attributes. Geospatial APIs are foundational for scientific computing, urban analytics, planetary research, public health surveillance, and geospatial-AI workflows, enabling programmable access to distributed spatial resources and seamless integration across data repositories, sensor infrastructures, visualization platforms, and analytic pipelines.

Types are meant to be shared across systems, while models are system-specific. Your project structure should reflect this separation.

A well-implemented Taxi ecosystem has clear separation between shared semantics and system-specific implementations.

A mature implementation typically includes: ​ Shared Taxonomy Collection of semantic types Broadly shared across organization Version controlled and carefully governed Published as a reusable package ​ Service Implementations Models and service definitions using types from taxonomy System-specific structures Published to TaxiQL server (like Orbital) Each service depends on shared taxonomy ​ Data Consumers Import shared taxonomy only Don’t depend on service-specific models Query data using TaxiQL Receive data mapped to their needs ​

Best Practices ​ Type Development Focus on business concepts Keep types focused and single-purpose Document type meanings clearly Version types carefully ​ Model Development Use semantic types for fields Keep models service-specific Don’t share models between services ​ Service Integration Publish service contracts to TaxiQL server Use semantic types in operation signatures Let TaxiQL handle data mapping

Measuring Success Your implementation is successful when: Services can evolve independently Data integration requires minimal code New consumers can easily discover and use data Changes to one service don’t cascade to others Semantic meaning is preserved across systems