1. 76

  2. 18

    I am extremely happy that people are actually thinking about the real problems with SQL (not the MongoDB-inspired ones). I am going to monitor progress here, because I have long lamented the badness of SQL.

    1. 2

      I’ve always wondered what an RDBMS (good) would look like without SQL (flawed) - maybe it’d be more like QUEL…

      1. 1

        Thank you!

      2. 10

        If you find this interesting, you absolutely should read The Third Manifesto (PDF Warning).

        It is an attempt to put relational database languages on a firm, type-safe basis while still leveraging the power of the relational algebra. It’s also just a really fun read.

        1. 3

          EdgeDB/EdgeQL conforms to many (but not all) of the D proscriptions.

          1. 6

            1st1 says in their profile that they’re an EdgeDB employee. Are you?

            1. 3

              Yes, he’s EdgeDB co-founder and the author of the linked blog post.

              1. 12

                Ok, thanks. Just like to be sure about that when I’m reading articles about products and related tech. This is a good one. Welcome to Lobsters to the both of you. :)

                1. 4

                  Thank you! :)

            2. 3

              Python is an unusual choice for a database. Do you not expect latency/performance to be an issue?

              1. 4

                We’ve managed to squeeze a lot of performance out of Python and there are ways to do way more. Python has been amazing at allowing us to iterate quickly. That said, the current plan is to slowly start rewriting critical parts in Rust.

                1. 2


                  Any plans for a Rust language interface? I have a medium sized database-oriented project in Rust and it would be cool to try rewriting part of it for EdgeDB.

                  1. 2

                    Not yet. Maybe you want to help us implement it? :)

                    1. 3

                      I would love to, in my Copious Free Time. …of which I have none. It’s very tempting though.

                  2. 1

                    Sounds good, thanks for the insight :)

                  3. 2

                    We’ve posted some initial benchmarks here: https://edgedb.com/blog/edgedb-1-0-alpha-1/

                  4. 2

                    Could you elaborate?

                2. 7

                  No mention of datalog, which has been applied very successfully in Datomic?

                  Dedalus is another datalog project, introduced in this very Interesting talk: https://www.youtube.com/watch?v=R2Aa4PivG0g&t=2295s

                  1. 1

                    I’m curious, have you had success with Datomic in production? IME “successful” is not the appropriate adjective, not that that is a reflection on datalog itself.

                  2. 6

                    Really interesting article, and really interesting project, looking forward to try it out! On a completely off topic point, I wish languages had support for custom strings like raw strings, regex strings but for queries, etc. For example:

                    q = [SQL]"""
                    SELECT * FROM table;

                    so that editors can actually highlight the text in the proper colors, and so that we can static check the queries.

                    1. 5

                      FWIW, JavaScript has this feature, although I’m not sure there is a standard SQL ‘tag’ (in their parlance).


                      It also lets you introspect the string at runtime. Doing it at compile time also seems possible as long as the interpolations is “well behaved”.

                      1. 3

                        I didn’t know that javascript template strings have a tag, this is literally what I wanted. Thanks a lot:)

                      2. 3

                        I don’t know if this has been implemented for SQL, but this should be possible in Rust with macros. Similar things have been done - see typed-html for example.

                        1. 2

                          This is really interesting, I’ve seen the project before and I was quite surprised by it, though I was thinking of something a bit more cross language like SQL queries with proper SQL syntax. It could be also interesting for code templates generation.

                        2. 2

                          Lua does.

                          q = [[
                          SELECT f1,f2,f3 FROM table
                          WHERE status = 1;

                          You lose the traditional characters escapes like ‘\n’ though. Syntax highlighting might be a trick, but the editor could look for a comment like:

                          q = --[[ SQL ]] [[
                          SELECT f1 ...
                          1. 1

                            This is really cool. I’ve never used Lua, but that’s more or less what I wanted.

                        3. 6

                          To all interested, here’s a blog post about first alpha release of EdgeDB: https://edgedb.com/blog/edgedb-1-0-alpha-1

                          It contains benchmarks against Django, SQLAlchemy, MongoDB, and handwritten SQL queries.

                          1. 4

                            graphql-meets-protobuf, built on top of postgres. No thanks.

                            1. 9

                              … that sounds kinda good to me. Why don’t you like it?

                              1. 2

                                yeah that comment actually made me go read the article :)

                            2. 4

                              The major theme I see is that in SQL, once you’ve got one part of the expression worked out, it’s not necessarily going to be a direct subexpression of the larger query you’re trying to construct. This can be described as composition by juxtaposition, and it’s valuable. SQL missed the trick on this one, so it’s not a surprise that many SQL replacements focus on this (directly or indirectly).

                              q/kdb is worth looking at since it has this feature too. Consider:

                              select name,(exec deptno!name from emp where role=`dept_head)no from dept
                              select avg x from select x:count i by description from reviews
                              select avg x, max x from select x:count i by description from reviews

                              You want views? You’ve got them:

                              s::select x:count i by description from reviews
                              select avg x, max x from s

                              Nested trees? Nested data!

                              select description, (select[>last_name] first_name, image from directors),
                                (select[>last_name] first_name, image from cast),
                                (select[>creation_time] body,rating,(select name, image) from author from reviews)
                                from movies

                              Piece of cake! q/kdb supports tables (and dictionaries) as regular data types, including nested in a column. No need to join anything if your data is already the right shape!

                              1. 3

                                The article makes some good points. The database itself is apparently built on PostgreSQL, so maybe there’s a chance to get a EdgeQL->SQL compiler out of this?

                                Source repository here: https://github.com/edgedb/edgedb It turns out this is built in python, properly embedding postgresql.

                                1. 4

                                  so maybe there’s a chance to get a EdgeQL->SQL compiler out of this?

                                  There’s a compiler inside EdgeDB but there are no plans on offering a standalone version of it. The reason is that EdgeDB has a lot more layers than just that compiler, i.e. the data model and schema are different from SQL. If you like EdgeQL, the only way to try it (currently) is to use EdgeDB.

                                2. 3

                                  This looks quite interesting. The language looks like a strange mix between SQL and JSON, but somehow I’m having some trouble convincing myself that this really is more composable than SQL.

                                  1. 7

                                    I’d say it’s closer to GraphQL, although it is way more powerful. Perhaps this documentation page can tell you more about composition: https://edgedb.com/docs/edgeql/expressions/shapes

                                    1. 8

                                      I’m impressed by the amount of thought (and work) that went into this. I think the decision to make your own client library for Postgres was probably the right one. Binding libpq brings lots of advantages out of the box, like automatic parsing of .pgpass, environment variables and so on, but it looks like even these things have been re-implemented. Really cool!

                                      Dammit, now I’m all excited :) Now I’m going to have to consider if I want to make a CHICKEN binary Postgres protocol implementation :) It looks like the “automatic” parsing of composite objects you get “for free” is a killer feature. I’ve always thought mapping custom types from the db to types in the programming language is extremely powerful and not used enough. And the performance benefits of not having to parse text (and serialize it on the server) are the cherry on top.

                                      Thank you for this inspiring stuff!

                                  2. 2

                                    Yes, we can do better than SQL. I’m glad people are actually doing so now. :-)

                                    1. 2

                                      What is the monetization scheme here? Is it another elasticsearch/mongodb?

                                      1. 4

                                        It’s a bit too early to talk about monetization, but the database itself is fully open source under Apache 2.

                                        1. 3

                                          I think many companies made this “too early to talk about monetization” mistake. I wish you figure it out.

                                          1. -1
                                            1. Split it out into something that can be loaded into standard postgres
                                            2. Sell with a simple license
                                            3. Create similarly affordable Django db interfaces and other such products

                                            The greediest reptilian capitalists will worry about license management and the neckbeardiest freetards will be offended at having to pay, but demanding users to switch - for ostensibly only syntax - is a loss only to the company itself.

                                          2. 2

                                            If you have employees, you need monetization. If you have secret plans, feel free to ignore this comment. Otherwise, consider a prohibitive license like the AGPL on the spec and a permissive license like MIT for the code. Since you are the same group developing both, you get to license things how you please. Then sell support, and negotiate for royalties with paid databases in exchange for them using your language.

                                        2. 1

                                          For those of us who cannot use a package manager to install the package, yet want to use the directory structure to cast the package into something useful (think ArchLinux and pacman), it would be nice to be able to download the .deb or .rpm directly instead of meeting a “403 Forbidden”.

                                          1. 3

                                            Yes, I’ll look into enabling autoindex there. Meanwhile, here’s a direct link to the RPM package: https://packages.edgedb.com/rpm/el7/edgedb-1-alpha1-1.0a1-3.el7.x86_64.rpm

                                            1. 1

                                              Sweet, thanks!