7 ms·

I think "ease of use" over SQL is not the hill I would die over if I were trying to displace SQL. It's far too embedded throughout the entire industry and as a

I think "ease of use" over SQL is not the hill I would die over if I were trying to displace SQL. It's far too embedded throughout the entire industry and as a data analyst, learning EdgeQL vs SQL and then being locked into a new startup database that could disappear in a year doesn't seem like a high probability strategy. I wish the people all the luck but unfortunately SQL is "good enough", pretty standardized (I can use just about any relational database and get useful data by knowing the basics). The inconsistencies may be mathematically "ugly" but it's not hard to wrap your head around and overcome.

save_ferris 7y ago
Totally agree. It’s a bedrock technology that’s near-universal as far as company needs, at least in startup and web development environments. The JS framework churn makes me super appreciative of the stability that SQL brings.
- a13n 7y ago
  JS framework churn isn't what it was five years ago
  - wbrasky 7y ago
    You're right, it's far far worse now.
    - tlrobinson 7y ago
      Citation needed? I've been using React for 5 years and don't foresee not using it any time soon. Even if it's still true, "churn" translates to progress. It would be hard to argue complex web application UI development isn't better off now than it was 10 years ago.
      - geezerjay 7y ago
        > Citation needed? I don't have a citation, but a colleague of mine who's working on front-end projects repeatedly complains that today's JS stacks require half a dozen base JS packages, which in turn download dozens if not hundreds of ancillary packages, not to mention requiring a couple of transpilers and a bunch of tooling. And for what? Well, just to be able to render some text and a couple of buttons. Nowadays we have whole server projects that take less than 50MB of source code and dependencies to build, while a miserable SPA with a login screen and a couple of menus and buttons requires nearly 400MB of JS. That's pretty bleak.
        tlrobinson 7y ago
        Serious question: why do you care about 400MB vs 50MB of dev dependencies? Is your internet connection slow? Are you running out of hard drive space? There are projects like create-react-app and Parcel which offer very reasonable zero-configuration toolchains. If you care a lot about runtime dependency weight, there are lightweight libraries like Preact (3kB).
      - deleted 7y ago
        [deleted]
  - irrational 7y ago
    I know. Things were so much nicer 5 years ago just before React, and the other myriad frameworks we have now, came out.
    - tlrobinson 7y ago
      Out of curiosity, which frameworks/libraries are you referring to, and why do you think they are nicer than the "UI as a function of state" style libraries like React?
ericb 7y ago
The middlebrow dismissal strikes again! Why is it so hard to imagine something displacing SQL? A simpler, more predictable syntax seems perfectly plausible--it could ship alongside SQL. Do we have StockHolm Syndrome? The negativity is surprising and at the same time predictable.
- hobs 7y ago
  Because of the decades of things not displacing it - when someone suggests "oh we'll just do it simpler" they often are not seeing the forest for the trees. Simpler languages have been shipped dozens if not hundreds of times, and they generally tend towards expressing the things they missed or not giving enough functionality for the things they missed. I am not saying its impossible, but you're going to have to do a lot more than hand waving to justify the reverse position.
  - chuckgreenman 7y ago
    It's sort of like the mouse trap problem. Mouse traps and SQL are already incredibly simple and incredible effective, that's why you don't see a reinvented mouse trap at home depot and why SQL remains unseated despite many efforts to replace it.
    - adamlett 7y ago
      You really think SQL is incredibly simple? I think TFA makes a pretty convincing argument that it is anything but.
      - chuckgreenman 7y ago
        Certainly there are complex aspects of it but you could teach someone how to do most of what you need to do in SQL in under an hour.
      - darkpuma 7y ago
        Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. Yes you can make some lovecraftian horrors if you really want to, but SQL is one of those things where just a little bit of knowledge goes a long way. If you can understand the basics you can get a lot of work done. It's a lot like Excel. You can do some really complex confusing stuff in Excel. But you can also teach the basics to non-programmers quite easily, and command of the basic skills will be very empowering. Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems.
ben_jones 7y ago
I accidentally built an in-memory database that now lives prominently in our production stack. It works great, its incredibly performant, the codebase is relatively simple (it makes heavy use of code-generation), it will scale very well - but not a day goes by I don't think what if I had just taken the time to adapt an existing solution to the problem set. There are just so many free things you get with SQL and established RDBMS that deeply impact application features, quality, stability, operations, and much, much, more. I've had to write a custom mongo-db like interface for querying, as well as a fair number of hacky bits to effectively cover the surface area of SQL in an inferior way. I've learned tremendously, but I just wish people don't follow in my exact footsteps because that's probably wasted time.
- dman 7y ago
  As someone who landed up doing what you did, I also had days where I felt what you have described here. On the other hand by going custom you can usually exploit some understanding you have of your problem to great effect.
- pstuart 7y ago
  SQLite is a wonderful tool for such a scenario.
nine_k 7y ago
A good replacement tech usually gets piggy-backed on the tech it's going to replace. That is, a reliable tool that translates 99% of normal SQL into readable Edge SQL, and vice versa, would help adoption a lot. Remember how new JavaScript features became mainstream though transpiling, long before native implementations.
- numbsafari 7y ago
  Agreed. I think this is one reason that Looker's LookML has been successful. Not that it's entirely what I'd want out of a "SQL replacement", but it's an enhancement that "compiles" down to SQL rather than looking to replace it. Plus, you can always go direct to SQL, in case you need to take advantage of some specific feature or complexity that their language doesn't address itself.
- eanzenberg 7y ago
  No it won't, because you add immense friction for no added features.
  - nine_k 7y ago
    Composability is quite a feature for me.
weberc2 7y ago
SQL is good enough for the existing set of applications, but that's not really saying much. There are lots of other applications for which SQL is not good enough, and those applications either don't exist because an affordable alternative doesn't exist or they implement their own proprietary database (e.g., many popular BI tools). It's safe to say that your use case--using SQL to perform one-off queries--is fine; writing a program that can dynamically build (performant) SQL to access data of arbitrary schema is quite a lot harder even if you can assume a single implementation. And much of this difficulty comes down to lack of composability. Perhaps SQL is fine if it's your interface for accessing data on a one-off basis, but if you're trying to build a complex tool on top of it (say, an analysis tool for arbitrary data), the inconsistencies and performance concerns mount. People often end up inventing their own proprietary databases to do these analyses (e.g., virtually any business intelligence tool) assuming they can afford to do so. Perhaps EdgeQL isn't the ideal alternative, but as it is SQL is not good enough for many use cases.
- zaarn 7y ago
  SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query. In most cases when people feel like SQL cannot do something it is either because the Database does not implement a part of the standard or because they are not familiar with some of the more advanced usage of SQL. Simple SELECT FROM WHERE clauses, even including JOIN, are still fairly simple compared with what you CAN do if you want. I'd recommend reading the PGSQL manual, they go very in depth about many of the supported features and how they are implement and can be used.
  - perl4ever 7y ago
    "SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query." That's kind of orthogonal to what I think is the issue being expressed here. SQL can do many things; the problems tend to be when a query doesn't perform consistently and predictably. There's always a balance to be struck between communicating what is to be done, and how it is to be done, and SQL leaves so much of the "how" out that the query interpreter/optimizer is incredibly sophisticated and does a fantastic amount of work and yet frequently gets things spectacularly wrong, maybe due to misconfiguration and maybe due to fundamental limitations. Obviously more information on how to do something is not always better; otherwise we'd be using assembler. But there is a balance. Experts tend to say "write everything in one query, and if it doesn't work, fix the configuration of your database" which is not helpful given the division of responsibilities in any company. But they will say that because they are devoted to the idea that all that expressiveness is good for something.
BuckRogers 7y ago
Agreed on all of that. Further, I wouldn't embrace something intending to displace SQL without it being authored by someone like Anders Hejlsberg (Turbo Pascal, Delphi, C#, TypeScript). That sort of involvement grants confidence that it's as "correct" as it can be for most users. That matters for buy-in. It can happen, Kotlin is a decent example, but is not embraced as widely as TypeScript has been. I'm sure that confidence plays a big role there. The stakes are much higher here with SQL, than in Java or ECMAScript. There's plenty of brilliant people out there, but when you're talking about replacing the most successful data storage language in the history of mankind, you need everything. SQL has been "killed" many times, everyone wants to sell something. It would probably take involvement from a FAAMG entity. I think the first clue that there's no real room for technical innovation and we're staring at only the opportunity for technical churn, is that no FAAMG players, who definitely operate at-scale, have tried to displace SQL outright already. TypeScript or Kotlin are really the closest, best and most recent examples of what would need to happen. For me as an end-user, ubiquity and skill-reusability matters. If you don't like SQL, there are ORMs.
billman 7y ago
In the financial industry, I have a seen a couple places where SQL was the interface for their payment systems. Mind you that these payment systems were not written using any kind of relational paradigm.
everdev 7y ago
Same goes for JavaScript. It's so ubiquitous that it's worth putting up with the downsides. It'll take several unicorns and Fortune 100s hiring thousands of engineers to code in an SQL-alternative to create an ecosystem large enough to eventually overtake SQL.
- hudbuddy 7y ago
  This situation seems comparable to Typescript in this analogy. It has taken several years, but I feel like it is beginning to take hold.

save_ferris 7y ago

Totally agree. It’s a bedrock technology that’s near-universal as far as company needs, at least in startup and web development environments. The JS framework churn makes me super appreciative of the stability that SQL brings.

a13n 7y ago
JS framework churn isn't what it was five years ago
- wbrasky 7y ago
  You're right, it's far far worse now.
  - tlrobinson 7y ago
    Citation needed? I've been using React for 5 years and don't foresee not using it any time soon. Even if it's still true, "churn" translates to progress. It would be hard to argue complex web application UI development isn't better off now than it was 10 years ago.
    - geezerjay 7y ago
      > Citation needed? I don't have a citation, but a colleague of mine who's working on front-end projects repeatedly complains that today's JS stacks require half a dozen base JS packages, which in turn download dozens if not hundreds of ancillary packages, not to mention requiring a couple of transpilers and a bunch of tooling. And for what? Well, just to be able to render some text and a couple of buttons. Nowadays we have whole server projects that take less than 50MB of source code and dependencies to build, while a miserable SPA with a login screen and a couple of menus and buttons requires nearly 400MB of JS. That's pretty bleak.
      - tlrobinson 7y ago
        Serious question: why do you care about 400MB vs 50MB of dev dependencies? Is your internet connection slow? Are you running out of hard drive space? There are projects like create-react-app and Parcel which offer very reasonable zero-configuration toolchains. If you care a lot about runtime dependency weight, there are lightweight libraries like Preact (3kB).
    - deleted 7y ago
      [deleted]
- irrational 7y ago
  I know. Things were so much nicer 5 years ago just before React, and the other myriad frameworks we have now, came out.
  - tlrobinson 7y ago
    Out of curiosity, which frameworks/libraries are you referring to, and why do you think they are nicer than the "UI as a function of state" style libraries like React?

ericb 7y ago

The middlebrow dismissal strikes again! Why is it so hard to imagine something displacing SQL? A simpler, more predictable syntax seems perfectly plausible--it could ship alongside SQL. Do we have StockHolm Syndrome? The negativity is surprising and at the same time predictable.

hobs 7y ago
Because of the decades of things not displacing it - when someone suggests "oh we'll just do it simpler" they often are not seeing the forest for the trees. Simpler languages have been shipped dozens if not hundreds of times, and they generally tend towards expressing the things they missed or not giving enough functionality for the things they missed. I am not saying its impossible, but you're going to have to do a lot more than hand waving to justify the reverse position.
- chuckgreenman 7y ago
  It's sort of like the mouse trap problem. Mouse traps and SQL are already incredibly simple and incredible effective, that's why you don't see a reinvented mouse trap at home depot and why SQL remains unseated despite many efforts to replace it.
  - adamlett 7y ago
    You really think SQL is incredibly simple? I think TFA makes a pretty convincing argument that it is anything but.
    - chuckgreenman 7y ago
      Certainly there are complex aspects of it but you could teach someone how to do most of what you need to do in SQL in under an hour.
    - darkpuma 7y ago
      Most common SQL statements read like somewhat stilted english. Many non-programmers find this particularly accessible. Yes you can make some lovecraftian horrors if you really want to, but SQL is one of those things where just a little bit of knowledge goes a long way. If you can understand the basics you can get a lot of work done. It's a lot like Excel. You can do some really complex confusing stuff in Excel. But you can also teach the basics to non-programmers quite easily, and command of the basic skills will be very empowering. Basic knowledge of Excel, like SQL, gives the user new ways to leverage computers when creating their own solutions to their own problems.

ben_jones 7y ago

I accidentally built an in-memory database that now lives prominently in our production stack. It works great, its incredibly performant, the codebase is relatively simple (it makes heavy use of code-generation), it will scale very well - but not a day goes by I don't think what if I had just taken the time to adapt an existing solution to the problem set. There are just so many free things you get with SQL and established RDBMS that deeply impact application features, quality, stability, operations, and much, much, more. I've had to write a custom mongo-db like interface for querying, as well as a fair number of hacky bits to effectively cover the surface area of SQL in an inferior way. I've learned tremendously, but I just wish people don't follow in my exact footsteps because that's probably wasted time.

dman 7y ago
As someone who landed up doing what you did, I also had days where I felt what you have described here. On the other hand by going custom you can usually exploit some understanding you have of your problem to great effect.
pstuart 7y ago
SQLite is a wonderful tool for such a scenario.

nine_k 7y ago

A good replacement tech usually gets piggy-backed on the tech it's going to replace. That is, a reliable tool that translates 99% of normal SQL into readable Edge SQL, and vice versa, would help adoption a lot. Remember how new JavaScript features became mainstream though transpiling, long before native implementations.

numbsafari 7y ago
Agreed. I think this is one reason that Looker's LookML has been successful. Not that it's entirely what I'd want out of a "SQL replacement", but it's an enhancement that "compiles" down to SQL rather than looking to replace it. Plus, you can always go direct to SQL, in case you need to take advantage of some specific feature or complexity that their language doesn't address itself.
eanzenberg 7y ago
No it won't, because you add immense friction for no added features.
- nine_k 7y ago
  Composability is quite a feature for me.

weberc2 7y ago

SQL is good enough for the existing set of applications, but that's not really saying much. There are lots of other applications for which SQL is not good enough, and those applications either don't exist because an affordable alternative doesn't exist or they implement their own proprietary database (e.g., many popular BI tools). It's safe to say that your use case--using SQL to perform one-off queries--is fine; writing a program that can dynamically build (performant) SQL to access data of arbitrary schema is quite a lot harder even if you can assume a single implementation. And much of this difficulty comes down to lack of composability. Perhaps SQL is fine if it's your interface for accessing data on a one-off basis, but if you're trying to build a complex tool on top of it (say, an analysis tool for arbitrary data), the inconsistencies and performance concerns mount. People often end up inventing their own proprietary databases to do these analyses (e.g., virtually any business intelligence tool) assuming they can afford to do so. Perhaps EdgeQL isn't the ideal alternative, but as it is SQL is not good enough for many use cases.

zaarn 7y ago
SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query. In most cases when people feel like SQL cannot do something it is either because the Database does not implement a part of the standard or because they are not familiar with some of the more advanced usage of SQL. Simple SELECT FROM WHERE clauses, even including JOIN, are still fairly simple compared with what you CAN do if you want. I'd recommend reading the PGSQL manual, they go very in depth about many of the supported features and how they are implement and can be used.
- perl4ever 7y ago
  "SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query." That's kind of orthogonal to what I think is the issue being expressed here. SQL can do many things; the problems tend to be when a query doesn't perform consistently and predictably. There's always a balance to be struck between communicating what is to be done, and how it is to be done, and SQL leaves so much of the "how" out that the query interpreter/optimizer is incredibly sophisticated and does a fantastic amount of work and yet frequently gets things spectacularly wrong, maybe due to misconfiguration and maybe due to fundamental limitations. Obviously more information on how to do something is not always better; otherwise we'd be using assembler. But there is a balance. Experts tend to say "write everything in one query, and if it doesn't work, fix the configuration of your database" which is not helpful given the division of responsibilities in any company. But they will say that because they are devoted to the idea that all that expressiveness is good for something.

BuckRogers 7y ago

Agreed on all of that. Further, I wouldn't embrace something intending to displace SQL without it being authored by someone like Anders Hejlsberg (Turbo Pascal, Delphi, C#, TypeScript). That sort of involvement grants confidence that it's as "correct" as it can be for most users. That matters for buy-in. It can happen, Kotlin is a decent example, but is not embraced as widely as TypeScript has been. I'm sure that confidence plays a big role there. The stakes are much higher here with SQL, than in Java or ECMAScript. There's plenty of brilliant people out there, but when you're talking about replacing the most successful data storage language in the history of mankind, you need everything. SQL has been "killed" many times, everyone wants to sell something. It would probably take involvement from a FAAMG entity. I think the first clue that there's no real room for technical innovation and we're staring at only the opportunity for technical churn, is that no FAAMG players, who definitely operate at-scale, have tried to displace SQL outright already. TypeScript or Kotlin are really the closest, best and most recent examples of what would need to happen. For me as an end-user, ubiquity and skill-reusability matters. If you don't like SQL, there are ORMs.

billman 7y ago

In the financial industry, I have a seen a couple places where SQL was the interface for their payment systems. Mind you that these payment systems were not written using any kind of relational paradigm.

everdev 7y ago

Same goes for JavaScript. It's so ubiquitous that it's worth putting up with the downsides. It'll take several unicorns and Fortune 100s hiring thousands of engineers to code in an SQL-alternative to create an ecosystem large enough to eventually overtake SQL.

hudbuddy 7y ago
This situation seems comparable to Typescript in this analogy. It has taken several years, but I feel like it is beginning to take hold.