Data API Gateways

Tools that turn a database (usually Postgres) into a REST or GraphQL API without writing a server. Distinct from generic API Gateways (which route HTTP across services) — these generate the data API surface from a schema. Often paired with Auth for row-level security and Semantic Layers & Metrics for metric-shaped APIs.

REST over Postgres

• ★ PostgREST — single binary; turns any Postgres schema into a REST API; uses Postgres roles + RLS for auth. PostgreSQL license. Tiny ops surface; the default OSS pick.
• ★ Supabase REST — bundled with Supabase; PostgREST under the hood + auth, storage, realtime; see Databases & ORMs.
• Postgrest-go — Go reimplementation; smaller community.

GraphQL over Postgres / DBs

• ★ Hasura — GraphQL + REST + JDBC connectors; Apache 2.0 (Community Edition) and paid Cloud / Enterprise. The most-feature-complete OSS data-API gateway in 2026; works on Postgres, MySQL, SQL Server, BigQuery, Snowflake, ClickHouse.
• ★ PostGraphile — GraphQL from a Postgres schema; MIT (v4) / dual-licensed (v5); strong RLS-based auth model; smaller surface than Hasura.
• Grafbase, Apollo Connectors — GraphQL-federation-flavored; not auto-generated, but power similar use cases.
• GraphJin — Go binary; GraphQL over Postgres / MySQL; Apache 2.0; smaller community.

NoSQL / multi-DB

• MongoDB Atlas Data API — REST API over Atlas clusters.
• FerretDB — Mongo-wire-compatible Postgres front end; Apache 2.0; useful when you want Mongo's API but Postgres storage.
• DynamoDB Data API, Cloudflare D1 HTTP API — managed-DB-specific.
• AWS API Gateway → Lambda → DB — the manual approach.

Backend-as-a-service / DB+API in one

• Supabase — Postgres + auth + storage + Edge Functions + realtime; see Databases & ORMs.
• Pocketbase — single Go binary, SQLite-backed; MIT; great for tiny projects.
• Appwrite — open core; broader BaaS scope.
• Convex — TypeScript queries against a typed document DB; see Databases & ORMs.
• Nhost — Postgres + Hasura + auth + storage; open source.

SQL APIs and federation

• Trino, Presto — federated SQL over many sources; see Query Engines & Federated SQL.
• Spice.ai OSS — embeddable SQL data-fabric over many sources; Apache 2.0.
• Steampipe — SQL APIs over SaaS / cloud-provider APIs; AGPLv3.

Patterns to know

• RLS is the auth model. Postgres row-level security policies become the API authorization. Don't try to layer it on top of PostgREST in middleware.
• Use views for shape. Don't expose raw tables; build views that match the API contract you want.
• JWT for identity. Sign a short-lived JWT in your auth layer with role and user_id claims; PostgREST / Hasura verify it natively.
• Don't expose write-mutations carelessly. Lock down which roles can INSERT / UPDATE / DELETE; default to read-only views for public consumers.
• Cache aggressively. GraphQL / REST responses cache well; PostgREST works behind any HTTP cache. Hasura has built-in query caching in CE.
• Schema migrations are your API contract. Add columns are safe; renames break clients. Treat the API like any other.

Pick this if…

• Default new project, REST, OSS: PostgREST (or Supabase if you also want auth + storage).
• Default GraphQL over Postgres + multi-DB: Hasura.
• Postgres-only GraphQL with great schema introspection: PostGraphile.
• You want full BaaS, OSS: Supabase, or Pocketbase / Appwrite for smaller projects.
• Federate over warehouses: Trino + a thin REST shim, or Spice.ai OSS.
• Need a hosted GraphQL gateway: Hasura Cloud or Apollo.