Wow, EdgeQL looks amazing! I've spent a good amount of time looking into SQL alternatives and building my own, and this is the only one that feels like "I must try this!" (Too bad my current project has no need for a DB; now I have a dilemma...)

> You can run EdgeDB as a query engine on top of an externally hosted Postgres instance or let EdgeDB manage Postgres for you under the hood.

This is excellent. Allows me to use EdgeDB for the majority of my application, but still treat it as a "plain old Postgres DB" when needed.

I found EdgeDB today via the article "Against SQL" (which triggered so many pain points), and now rewriting one of the projects to use it. I know it's not production ready, but it looks too good not to try.

Let us know how it goes!

Thanks for the kind words!

Also feel free to play with EdgeDB in your browser with our interactive EdgeQL tutorial: https://www.edgedb.com/tutorial

I'm a SQL newbie so maybe I lack context for this decision, but why did you decide to keep the "SELECT" keyword? Going through your tutorial, SELECT seems redundant and could just be dropped without any loss of information. In that way look a lot more like most non-SQL languages. Why do I need to SELECT "string" instead of just "string"?

Off the top of my head: EdgeQL grammar is relatively complex and we need SELECT to disambiguate in many corner cases.

I'm trying to understand how this tutorial works, I noticed it doesn't make any network requests when run one of the examples, but then if I edit the code in an example it does make a request. Is this the magic of next.js and server-side components at work, and do you have a real edgedb running on the server side that is used to pre-render the page and also handle updates? I would love to hear more about how this setup works and even look at the code if it's available.

You guessed everything right: we run an instance to prerender and cache at the build time and at runtime we query when the query has been changed

If there is one piece of techno I have my eyes on since some time, and am the most exited about, it’s EdgeDB. You guys have nothing to prove anymore. I’m using your work on a daily basis: asynpcg, uvloop, black and … python !

When I came across the EdgeDB project, I thought: “damn it’s too good on the paper to be true”. And when I watched the 6th video of “import asyncio” from Łukasz on your YouTube channel, it blew my mind the kind of queries one could achieve, and how flexible was the schema definition with the abstract types.

Although I’ll have to be a bit more patient to push this techno at work, I’m even orienting my personal projects to be a fit for edgedb usage.

Please keep up with the awesome work !

My top features on the roadmap for 1.x:

- LSP

- Query Builders and Schema Reflection

- Fine-grained Data Access Control Rules

Thank you :)

Do you have any simple mechanism for bulk import, either from CSV or JSON files, or existing Postgres? Googled a bit and didn't see how to bulk load an existing dataset.

There aren't any special "bulk" interfaces at the moment, you can load data via a small program using our language bindings (INSERT in a loop). We'll add support for batched `executemany()` soon to cater to very large loads specifically. A similar optimization in asyncpg [1] led to a 10x improvement in throughput (~100Krec/sec per connection), and we expect similar performance from EdgeDB once the protocol and the bindings are updated.

Loading arbitrary JSON by introspecting the data, and auto-generating the schema and the necessary DML statements is fairly straightforward too. I have a rough Python proof-of-concept, will need to find time to finish and publish it.

[1] https://github.com/MagicStack/asyncpg/pull/295

Really nice 1st1 - congrats, all your resources look so clean.

Thanks! :)

> that aims to surpass SQL in querying power.

What makes your approach likely to succeed versus all previous attempts to supplant SQL in the last 40 years?

We've spent years in R&D mode working on the data model, the query language, APIs and architecture to make sure that everything clicks together to create one vertically integrated, cohesive, and language agnostic solution. Everything in EdgeDB is optimized for DX (while not sacrificing perf or type safety), and as far as I know there's no other database company out there which does what we do. So fingers crossed, our attempt at evolving relational databases will be successful.

Everything you said sounds like Britton-Lee's database. What is new?

I'm not intimately familiar with that particular piece of history, unfortunately (I'll read more about it for sure). There were many examples in the past of great tech (like smalltalk or network dbs) that didn't exactly succeed for many reasons, sometimes because it was created way ahead of its time. We build EdgeDB to address today's needs: nested hierarchical queries, integrated schema migrations, performance, high quality language drivers etc. There is some intersection with what was done in the past for sure, but if you're interested in databases I encourage you to take a look at our website, the blog, and the docs. I'm sure you'll find new things.

Just discovering EdgeDB. How does it handle graph queries (specifically, traversing joins across > 3 tables under the hood)?

It handles them just fine. Any single EdgeQL query always compiles to just one SQL query under the hood. We wrap nested hierarchy levels subqueries in array_agg and our binary protocol is designed in such a way that unpacking the results is very fast.

EdgeQL lets you do arbitrary joins as well. Here's how you could compute salaries of employees by department even if you for some reason don't have a link between Employee and Department:

    SELECT Department {
        name,
        employees := (
            SELECT Employee { name, salary } 
            FILTER Employee.department_name = Department.name
        )
    }
   

Links in EdgeQL are merely an abstraction over the fact that most joins in a well-normalized schema are done over primary keys.

How do I join tables 1:1 without creating a subfield, i.e.:

table1: id, name

table2: table1_id, level

Desired result:

{id, name, level}

The most direct implementation of what you want would be:

  SELECT (Table1.id, Table1.name, Table2.level, Table2.table1_id)
  FILTER Table1.id = Table2.table1_id;

(This has a somewhat annoying extra output of table1_id, which could be projected away if necessary.)

If you want to use edgeql's shapes but still keep the essential join flavor, then something like:

  SELECT (Table1 { id, name }, Table2 { level })
  FILTER Table1.id = Table2.table1_id;

To make it a little more concrete, you can try this on the tutorial database (https://www.edgedb.com/tutorial)

  SELECT (Photo {uri}, User {name, email})
  FILTER Photo.author.id = User.id;

The tutorial database uses links, and so instead of having an author_id we have author.id, but having an author_id property would work just fine---except that then you'd have to do all the joins manually.

You do joins when you traverse schema type paths in EdgeQL, it's just that the actual joins are implicit (well, compared to SQL):

  SELECT User {
    email,
    preferences: {
      name,
      value
    }
  } FILTER .id = '...'

E.g. in the above example we'd join the underlying User and Preferences tables for you.

You can also do cross joins and all other funky stuff.

How would you represent a self join?

If given a recursive schema like this:

    type Tree {
        property value -> str
        link parent -> Tree
    }
    

you'd traverse the link as usual:

    SELECT Tree {
        value,
        parent: {
            value
        }
    }
    FILTER .parent.parent.parent.value = 'foo'
    

If there's a need to self-join on an arbitrary property, then you could use a `WITH` clause to explicitly bind the two sets:

    WITH
        T1 := Tree,
        T2 := Tree
    SELECT
        T1 {
            similarly_valued := (SELECT T2 FILTER T1.value = T2.value)
        }

Thanks!

Example from the cheatsheet:

``` WITH P := Person SELECT Person { id, full_name, same_last_name := ( SELECT P { id, full_name, } FILTER # same last name P.last_name = Person.last_name AND # not the same person P != Person ), } FILTER EXISTS .same_last_name ```

Is supporting MSSQL completely out of scope in not too distant future time frame?

Currently out of scope, sadly.