<story><title>Against SQL</title><url>https://scattered-thoughts.net/writing/against-sql/</url></story><parent_chain><item><author>slx26</author><text>I think the problem of this essay is that it&amp;#x27;s overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that &amp;quot;SQL will get the job done in the end&amp;quot;, or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when the essay kinda explains it main point pretty well:&lt;p&gt;&amp;gt;&amp;gt; The core message [...] is that there is potentially a huge amount of value to be unlocked by replacing SQL&lt;p&gt;To me, a lot of people defends SQL saying that &amp;quot;perfect is the enemy of good&amp;quot; and that SQL simply works. Not the favourite of anyone, but everyone kinda accepts it.&lt;p&gt;And yeah, it&amp;#x27;s true. People use SQL because it&amp;#x27;s good enough, and trying to reinvent the wheel would take more work (individually speaking) than just dealing with SQL as it is right now. For large organizations where the effort could be justified, all your engineers already know SQL anyway, so it&amp;#x27;s not so great either.&lt;p&gt;But for something so relevant as relational databases, perfect is not the enemy of good. &lt;i&gt;We do deserve better&lt;/i&gt;. We generally agree that SQL has many pitfalls, it&amp;#x27;s not great for any kind of user (for non-technical users, a visual programming language would work well here, more like what Airtable does, closing the bridge between spreadsheet and hardcore database, and for technical users, it does feel unwieldy and quirky). We should be more open to at least &lt;i&gt;consider&lt;/i&gt; critiques and proposals for better. We might find out that people, from time to time, are making some good points.</text></item></parent_chain><comment><author>barrkel</author><text>I think I&amp;#x27;m experienced enough to understand the article, and I agree. I&amp;#x27;ve written multiple optimizing SQL generators (altering generated SQL to access better plans), and rewritten hundreds of queries for better performance, which involves trying many semantically identical rewrites of the same query.&lt;p&gt;I agree with Jamie. I think SQL is irritatingly non-composable, many operations require gymnastics to express, and I&amp;#x27;d like a more expressive and regular language to write queries in.&lt;p&gt;I also suspect that such a language would be harder to optimize, and might be more practical to implement if it was less declarative and closer to the plan.&lt;p&gt;I also think that as you scale up, offloading computation to the database is a false economy. It&amp;#x27;s closer to the data, but the database itself is a bottleneck. As you scale, you want to limit the complexity of your queries. But this is actually an argument for things like Materialize, i.e. making copies of the data elsewhere that bake in some of the computation ahead of time.</text></comment>
<story><title>Against SQL</title><url>https://scattered-thoughts.net/writing/against-sql/</url></story><parent_chain><item><author>slx26</author><text>I think the problem of this essay is that it&amp;#x27;s overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that &amp;quot;SQL will get the job done in the end&amp;quot;, or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when the essay kinda explains it main point pretty well:&lt;p&gt;&amp;gt;&amp;gt; The core message [...] is that there is potentially a huge amount of value to be unlocked by replacing SQL&lt;p&gt;To me, a lot of people defends SQL saying that &amp;quot;perfect is the enemy of good&amp;quot; and that SQL simply works. Not the favourite of anyone, but everyone kinda accepts it.&lt;p&gt;And yeah, it&amp;#x27;s true. People use SQL because it&amp;#x27;s good enough, and trying to reinvent the wheel would take more work (individually speaking) than just dealing with SQL as it is right now. For large organizations where the effort could be justified, all your engineers already know SQL anyway, so it&amp;#x27;s not so great either.&lt;p&gt;But for something so relevant as relational databases, perfect is not the enemy of good. &lt;i&gt;We do deserve better&lt;/i&gt;. We generally agree that SQL has many pitfalls, it&amp;#x27;s not great for any kind of user (for non-technical users, a visual programming language would work well here, more like what Airtable does, closing the bridge between spreadsheet and hardcore database, and for technical users, it does feel unwieldy and quirky). We should be more open to at least &lt;i&gt;consider&lt;/i&gt; critiques and proposals for better. We might find out that people, from time to time, are making some good points.</text></item></parent_chain><comment><author>ako</author><text>There&amp;#x27;s a lot of talk about what is wrong with SQL, but i haven&amp;#x27;t seen something yet that is actually better than SQL for most use cases.&lt;p&gt;Stop fighting SQL so much, and just focus on bringing a better solution. If potential users see it has significant benefits they&amp;#x27;ll start using it.</text></comment>