Relational is more than SQL

This is a very interesting way to promote a product, credit to the author (who is an industry veteran it seems).<p>I had no idea what Fauna was. I just clicked the link here because the title caught my eye (I work with databases quite a bit).<p>The opening paragraph immediately grabbed my attention - &quot;My first deep dive into SQL was in 1987, just before I became the first technical person at Microsoft to work on SQL Server.&quot; - woah!<p>So I read this entire article, which is very well written and easy to read but mostly affirms what I already know.<p>And then I get to the final section where they promote Fauna - and so now I know about Fauna too.<p>Kudos to these folks, in my humble opinion, this is marketing done right.

Disclaimer: I&#x27;m a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people&#x27;s threads, but for people interested in the headline, PRQL might be of interest.<p>At PRQL[1] we believe that SQL is a combination of two things:<p>1. Relational Algebra, which is eternal because it&#x27;s just maths, and 2. A language designed in the 70s that looks like COBOL.<p>When people say that SQL will never die, they are usually thinking about Relational Algebra because SQL has been used interchangeably with that. With PRQL we agree that Relational Algebra is fundamental to thinking about data and we intend to keep that. However we&#x27;ve learned a lot about programming languages in the last 50 years and so PRQL is a revamp of SQL that brings the composability of functional languages and modern ergonomics to data transformations in order to improve the DX and UX of data scientists, data analysts and analytics engineers.<p>PRQL is simply a compiler that produces SQL so you can use it with whatever database you are currently using. It&#x27;s completely open source with zero commercial associations and is deeply committed to staying that way forever.<p>1: <a href="https:&#x2F;&#x2F;prql-lang.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;prql-lang.org&#x2F;</a>

Nitpick, but relational does not mean joins, it means tables&#x2F;rows of tuples. A &quot;relational document database&quot; which is the slogan of Fauna it seems is a contradiction in terms.

Worthless article. Zero useful description of what it&#x27;s trying to sell. A bunch of disjoint historical facts about relational databases that have nothing to do with the product being sold take about 2&#x2F;3 of the article.<p>Also the author seems to be very proud of associating themselves with Microsoft&#x27;s products (w&#x2F;o even a hint of doubt that that may not show them in favorable light)...<p>Also, marketing-inspired use of pseudo-programming terminology (eg. &quot;dynamic languages&quot;). Ewww.

Seems like a lot of what fauna does by storing documents isn’t really new, oracle, Postgres and others have provided this for a long time. I was really surprised by the performance of json queries [1], opens the doors to using Postgres as a client api cache, storing the payload in a table, and doing deserialization using (materialized) views.<p>Difference seems to be the approach to minimize number of calls from your application, get all require session data in one call, similar to what graphql is doing for api calls. They’re also using http as the protocol for database connectivity.<p>[1]: <a href="https:&#x2F;&#x2F;ako.github.io&#x2F;blog&#x2F;2023&#x2F;08&#x2F;25&#x2F;json-transformations.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;ako.github.io&#x2F;blog&#x2F;2023&#x2F;08&#x2F;25&#x2F;json-transformations.h...</a>

Re PRQL … I see it like my text editor. I’ll stick with vi because it has solved text editing. It’s done. Same with SQL. I’ve not seen anything yet ready to replace it. It’s not perfect. But for what I need from it it’s perfectly serviceable.

On strong schemas and flexibility:<p>1. You still have a schema in your code. With weak schemas it&#x27;s now just harder to know if every record in your database conforms to it.<p>2. An ORM is a great tool for prototyping. R.g. have SQLAlchemy objects in code, run a command to generate a database migration; run the migration, and you have all your data guaranteed to be compatible with your latest code, and you didn&#x27;t write any SQL.

&gt; Most importantly, SQL databases made supporting highly consistent ACID transactions easy.<p>The default transaction isolation level for every major database is not ACID. Enabling the required serializability tends to make performance terrible, and so most don&#x27;t.

I have to say this was written extremely well. Quite cogent and I feel I learned a little something. Bookmarking this as a pretty decent intro to this area that I can refer people to.

Fixed schemas are good. Document stores are bad. SQL is good.<p>Stop doing this nonsense. It&#x27;s a step backwards. As the intro points out, hierarchical and graph DBs <i>came first</i>, and relational was built in part to solve their problems. Document DBs just bring those problems back.