I buy the need for something <i>like</i> FQL.<p>But I don’t buy that this should be connected to a proprietary service. Or that the alternative query language should be a proprietary language. For something long-term or critical, it seems like a pretty large business risk. We don’t have to use any imagination to see how this plays out — look at Oracle. Though it could be worse — imagine you build a successful business on it and they go belly up in ten years.<p>I think I’d like to see one of the various “XQL”s out there emerge as the modern query language and start getting adopted as a native alternative in existing engines.
I have to disagree with the following paragraph:<p>“SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure that is aligned with how the application needs to consume the result. ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database. They also obscure the structure of generated queries, making it difficult to understand the resulting performance implications.”<p>The ORMs or later mentioned GraphQL are not the only approaches to solving object-relational impedance mismatch.<p>SQL is perfectly capable of serializing sets of tuples to XML (part of the SQL standard), and most SQL RDBMS implementations now support working with JSON data.<p>Serializing using SQL to XML and in the past couple of years to JSON, and deserializing the said XML/JSON to an object model in the programming language of choice is something I’ve seen used fairly often in my career.<p>Heck, I’ve even seen entire business logic for a very complex system implemented via thousands of stored procedures that always returned XML. Prior to 2010, this was not the blasphemy it is made to be today…<p>So to reiterate my point, SQL is not inherently as inflexible as it was made to be here, thus neither ORM nor GraphQL are a necessity for dealing with SQL output inflexibility (and both can be very useful tools, as always, completely depending on the context).
> SQL query performance is opaque and dependent on an optimizer to make the right decision. The developer has imprecise control and a given query pattern's plan of execution is subject to change at unpredictable times.<p>This is really hilarious framing to me.<p>The <i>entire point</i> is to make the whole process opaque to the developer (unless they insist upon explaining a query plan). SQL is about maximizing productivity and focusing on the information of the business. Being able to write a SELECT statement that has <i>never been seen by any other computer on earth</i> and have it execute ideally 95%+ of the time is pretty close to pure magic.<p>Why would you reset 20+ years worth of experience on an existing SQL query planner/optimizer/et. al.? Wouldn't you rather build & ship a working product?
One of my side ideas is to write a postgres plugin offering an alternative syntax for queries, but one that requires you to name the index you use (or to explicitly mention a table scan).<p>I do understand the value of SQL + the planner for adhoc querying. But so many times I find myself reworking SQL to hint at the planner to use certain indexes, or to add "spurious" filters to make sure an index is used (spurious for application logic reasons). For applications with a relatively low cardinality of queries, some extra tedium might be worth stronger performance property guarantees.<p>Added advantage of the tedium is it would make a lot of "accidentally quadratic" stuff much clearer. There is no magic in the planner after all!<p>We can write inline assembler in C or Rust, it feels like it would make sense to offer something similar in SQL. Big problem is how to offer something that isn't too tedious.<p>Anyways FQL's index model seems to align with my idea, just unsure if I want the rest of it.
Fauna is really cool technology, but I'll note that it lacks interactive transactions as a core design constraint. That does enable a bunch of nice things. However, that means users lose one of the most useful parts of transactional SQL -- simple, safe read/modify/writes.<p>The only way is to ship all of the "modify" logic into the database via FQL. Given how many times I've seen code that does this unsafely with SQL, probably safe to say that if the bar is raised to "rewrite the logic in a foreign query language" developers will opt for thoughts and prayers instead.
This sales pitch sounds like they really just want to build a better ORM, but doesn't want to admit it, so they embark on the foolish task of reinventing SQL.<p>> ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database.<p>This is because all the popular ORMs target SQL instead of a specific RDBMS technology, like Postgres or SQLite. That doesn't have to be the case.<p>> They also obscure the structure of generated queries, making it difficult to understand the resulting performance implications.<p>Not quite true, Django for example makes it easy to do raw queries, and every generated query has .query() and .explain() methods to analyze the resulting SQL. This has always been a lame excuse to dismiss ORMs.
Good luck though, you're going up against giants (as much as this article portrays SQL as outdated, anyone who tries to go against it is very much the underdog). It's hard to get people to buy in on a custom database stack that is made by only a single company. And the fact that this article reads like a one sided praise for Fauna doesn't inspire confidence either, I want to read some real negatives from people who have used the thing.
A new DB, with a new query language that's like "SQL done right"? This immediately reminded me of EdgeDB: <a href="https://edgedb.com/" rel="nofollow noreferrer">https://edgedb.com/</a><p>Is there anyone here who knows enough about these two products to do a compare/contrast?
I tried to learn Fauna and FQL a couple of years ago; their documentation was hard to trudge through with few examples, and their pricing was hard to grasp.<p>I think they also recently nerfed the free tier.<p>I've been using CouchDB and Pocketbase.io much more successfully for my mini web apps.
People re-inventing SQL reminds me of the same people that keep trying to re-write standard Staff Music Notation.<p>Yeah, it's not perfect, but the suggested replacements are marginal gains, if anything.<p>In order to replace SQL, you probably need something like a 10x improvement, so it sells like hotcakes. Nothing about those examples screams that sort of improvement.<p>I mean, cool they put some stuff on the left instead of the right. And I guess the select clause is in a little better order now. Yay.
Of all the SQL flavors/derivatives, I like PRQL the most: <a href="https://prql-lang.org/" rel="nofollow noreferrer">https://prql-lang.org/</a><p>Previous HN discussion from a month ago: <a href="https://news.ycombinator.com/item?id=36866861">https://news.ycombinator.com/item?id=36866861</a>
I wrote my first self taught LAMP based miniSaas a few years ago. It has 34 paying companies using it with about 400 users total daily.<p>I want to write another soon. A free webapp saas type for consumers let's say.<p>Is there a reason I should learn this product instead of just continuing with modern mysql methods that seem to work and seem secure enough?
It always disappoints me when the example code (in the heading image) looks like it has a mistake:<p>SQL: WHERE category = "electronics"<p>FQL: where(.product.type == "Computers")<p>Also it changes case of USER to user between the two examples.<p>Minor mistakes like that hardly give one confidence in their product.
I have yet to come across a replacement for SQL that makes it easier, or more concise, while also remaining feature rich. Not knocking this, but SQL is a pretty solid and time-tested technology for querying structured data. Alas, if we don't experiment then I guess we wont get better.
I’m having a hard time understanding this line:<p>“Developers cannot take advantage of the full power of the underlying database for fear that the complex, opaque nature of SQL query behavior will overwhelm their ability to understand how queries perform, and quickly address problems when they do come up.”<p>What does that mean? Developers are somehow sacrificing database performance (“full power”) because they’re too scared to write SQL?
This bit:<p>> maladapted to modern cloud computing abstractions such as serverless, and is difficult to manage at scale.<p>Got me.<p>There’s little money in it but working in an infra role for a while now - I don’t really see rolling your own infra as becoming any easier which is so sad.
> Connection centric: SQL's session-based transaction model is maladapted to modern cloud computing abstractions such as serverless, and is difficult to manage at scale.<p>There's nothing connection-centric at all to the <i>language</i>.<p>> Inflexibility of result structure: SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure [...]<p>Many modern SQL-based RDBMSes provide JSON support for this. Some support row/record values, which is -in SQL- more natural than JSON.<p>> Complicated, irregular syntax:<p>Well, few like the SQL syntax -- there is that. I wouldn't say it's complicated syntax though.<p>> [...] and allows only limited forms of composition.<p>CTEs and subqueries are the main methods of composition in SQL.<p>> Opaque, unpredictable performance:<p>Yes, well, yes, of course, because SQL is declarative. That the programmer gets little control over the query planner is part of the point of SQL. The <i>query language</i> really needs to be like this. What could and should be done however is to have a) ways of addressing parts of the query, b) ways of specifying out of band (i.e., not <i>in</i> the query) hints or requirements for parts of the query's planning.<p>I really would like to be able to:<p><pre><code> - specify indexing for CTEs
- be able to pass in hints from outside
a query, like what table source to
make the "first" in a query plan,
what indices to use for specific
table sources, where constraints, etc.
</code></pre>
> Rigid tabular data model: Despite the theoretical adaptability of the relational model to many domains, the flat, uniform structure the traditional SQL database imposes on records is especially rigid, forcing a significant amount of upfront design.<p>I don't agree that this is a problem. You have to design your schema? The horrors.<p>> Introducing new query patterns and schema evolution is fraught with a significant amount of operational risk. Combined, these hinder iterative application development and risk locking in bad data model design decisions.<p>This is not exactly not true of alternatives to SQL-based RDBMSes...<p>TFA makes very strained arguments.<p>There are good arguments for a new language, but there's no need to make strained arguments along the way -- it detracts from TFA.