There's a lot of things you can do with a STAC catalog, both as a maintainer/provider and as a user:
- Search (aka "needle in a haystack"): Find one or a few items
- Full scan: Find most or all items
- Aggregations: Statistics on the STAC items
- Ingestion: Add one or more items to a catalog
- Dumps: Take all items out of a catalog into another format
- Migrations: Update a catalog to a new version or schema
Here's a rough comparison of each backend for each of these uses, as well as their maturity.
| pgstac | elasticsearch | stac-geoparquet | static | |
|---|---|---|---|---|
| Search | ✅ | ✅ | ❌ | |
| Full scan | ❌ | ✅ | ||
| Aggregations | ✅ | ✅ | ❌ | |
| Ingest | ✅ | |||
| Maturity | ✅ | ✅ | ||
| Dumps | ✅ | ✅ | ✅ | ✅ |
| Migrations | ✅ | ❌ | ❌ |
Here's a short description of each backend, with some links.
A Postgres/PostGIS schema for STAC. Excellent for large scale deployments, or if you already have a Postgres instance.
There's an API implementation that uses an elasticsearch/opensearch backend. There's no published schema for the *search indices, those are up to the instance.
A light specification for writing STAC into GeoParquet.
- Specification homepage
- Specification repo
- stac-geoparquet splash page
- stac-utils/rustac (low-level Python package)
- stac-utils/stac-geoparquet (higher-level Python package)
Some notes/caveats about the stac-geoparquet ratings in the tier list:
- stac-geoparquet's search performance is heavily influenced by the presence or absence of datetime sorting (e.g via a hash)
- Ingestion will be awkward until we build something, e.g. with iceberg
STAC catalogs can be statically hosted on blob storage as a collection of JSON files.