Against SQL

rw-book-cover

Metadata

Highlights

  • A shared universal data model allows cooperation between programs written in many different languages, running on different machines and with different lifespans. (View Highlight)

New highlights added February 22, 2023 at 4:42 PM

  • So while individual databases can be extended in many ways, the extensions can’t be shared between databases easily and the SQL spec is still left trying to eat the whole world. (View Highlight)
  • Because SQL is so inexpressive, incompressible and non-porous it was never able to develop a library ecosystem. Instead, any new functionality that is regularly needed is added to the spec, often with it’s own custom syntax. So if you develop a new SQL implementation you must also implement the entire ecosystem from scratch too because users can’t implement it themselves. (View Highlight)
  • The original idea of relational databases was that they would be queried directly from the client. With the rise of the web this idea died - SQL is too complex to be easily secured against adversarial input, cache invalidation for SQL queries is too hard, and there is no way to easily spawn background tasks (eg resizing images) or to communicate with the rest of the world (eg sending email). And the SQL language itself was not an appealing target for adding these capabilities. So instead we added the ‘application layer’ - a process written in a reasonable programming language that would live between the database and the client and manage their communication. And we invented ORM to patch over the weaknesses of SQL, especially the lack of compressibility. (View Highlight)
  • Similarly for firebase (before it was acqui-smothered by google). It dropped the entire application layer and offered streaming updates to client-side queries, built-in access control, client-side caching etc. Despite offering very little in the way of runtime innovation compared to existing databases, it was able to succesfully compete by recognizing that the current division of database + sql + orm + application-layer is a historical accident and can be dramatically simplified. (View Highlight)

title: “Against SQL” author: “scattered-thoughts.net” url: ”https://www.scattered-thoughts.net/writing/against-sql/” date: 2023-12-19 source: reader tags: media/articles

Against SQL

rw-book-cover

Metadata

Highlights

  • A shared universal data model allows cooperation between programs written in many different languages, running on different machines and with different lifespans. (View Highlight)
  • So while individual databases can be extended in many ways, the extensions can’t be shared between databases easily and the SQL spec is still left trying to eat the whole world. (View Highlight)
  • Because SQL is so inexpressive, incompressible and non-porous it was never able to develop a library ecosystem. Instead, any new functionality that is regularly needed is added to the spec, often with it’s own custom syntax. So if you develop a new SQL implementation you must also implement the entire ecosystem from scratch too because users can’t implement it themselves. (View Highlight)
  • The original idea of relational databases was that they would be queried directly from the client. With the rise of the web this idea died - SQL is too complex to be easily secured against adversarial input, cache invalidation for SQL queries is too hard, and there is no way to easily spawn background tasks (eg resizing images) or to communicate with the rest of the world (eg sending email). And the SQL language itself was not an appealing target for adding these capabilities. So instead we added the ‘application layer’ - a process written in a reasonable programming language that would live between the database and the client and manage their communication. And we invented ORM to patch over the weaknesses of SQL, especially the lack of compressibility. (View Highlight)
  • Similarly for firebase (before it was acqui-smothered by google). It dropped the entire application layer and offered streaming updates to client-side queries, built-in access control, client-side caching etc. Despite offering very little in the way of runtime innovation compared to existing databases, it was able to succesfully compete by recognizing that the current division of database + sql + orm + application-layer is a historical accident and can be dramatically simplified. (View Highlight)