What if an SQL statement returned a database?

Original Article ↗ Hacker News Discussion ↗

A new SQL extension proposes letting a query return a whole set of related tables—essentially a small, normalized “sub‑database”—instead of a single denormalized result table. Supporters see benefits for ORMs, hierarchical data, performance (less duplicated data over the wire), and preserving schema/key information, likening it to ideas from GraphQL, Datomic, and category‑theoretic databases. Critics counter that existing tools (joins, multiple queries, JSON/JSONB, stored procedures) already cover most use cases and argue that the added complexity and fuzzy terminology around “database” vs. “schema” may not justify a new language feature.

Concept: “SELECT RESULTDB” / Returning a Database-like Result

  • Proposal: extend SQL so a query can return multiple related tables (a “subset of the database”) instead of a single denormalized result set.
  • Think of it as a “normalized join”: you get separate relations for each table involved, with only the relevant rows, and preserved keys/relationships.
  • Intended to reduce data duplication in joins and maintain more schema/key information in the result.

Motivations & Use Cases

  • Performance: avoid repeating parent data in large join results; less data over the wire, especially in parent–child/snowflake schemas.
  • ORMs: easier to hydrate object graphs (e.g., recipes and ingredients, orders and customers) without N+1 queries or huge denormalized joins.
  • Latency: one round trip to fetch multiple related relations instead of many queries.
  • Consistency: a single query can provide a snapshot of related data that multiple queries could fetch inconsistently.
  • Potential fit for edge databases / local mirrors: fetch a “partial database” for offline or client-side querying.

Critiques & Skepticism

  • Many argue existing tools suffice: multiple queries (possibly in parallel), JSON/array aggregates, views, stored procedures returning multiple result sets, cursors.
  • Some see denormalized query results as a feature: queries are supposed to shape data into the desired format, not mirror schema.
  • Concern that constructing a “result database” in memory just shifts complexity to the client, which must query it again.
  • Some feel the paper misunderstands or misrepresents the relational model, or conflates “relational” with SQL’s limitations.
  • Others see this as syntactic sugar around packing/unpacking multiple relations.

Related Technologies & Prior Art

  • Comparisons to GraphQL, JSON:API, SQL JSON/JSONB support, SQL Server’s FOR JSON, ODBC/MARS multi-result sets, Akiban’s “nested result set”.
  • Links to category-theoretic “queries as morphisms between databases” and to graph/Datalog systems and Datomic-like “database as value” ideas.

Open Questions & Ambiguities

  • Exact semantics of keys, foreign keys, and aggregates (e.g., SUM, MAX) in a multi-table result are discussed but not fully settled in the thread.
  • How much real-world benefit it offers over compression and current patterns is debated and remains unclear.