[HN Gopher] EdgeDB: EdgeQL
___________________________________________________________________
EdgeDB: EdgeQL
Author : todsacerdoti
Score : 88 points
Date : 2021-07-10 14:01 UTC (8 hours ago)
(HTM) web link (website-atgsmhega-edgedb.vercel.app)
(TXT) w3m dump (website-atgsmhega-edgedb.vercel.app)
| 1st1 wrote:
| Hah, I'm not sure how our dev staging URL ended up on HN :)
|
| Here's a direct link to the documentation page about EdgeQL:
| https://www.edgedb.com/docs/edgeql/index.
|
| EdgeQL, the query language of EdgeDB, is a very interesting piece
| of tech. It's a new, strictly typed query language, that aims to
| surpass SQL in querying power. Functional in its nature it was
| designed to be composable and easy to learn. Happy to answer any
| kind of questions.
|
| EdgeDB itself is almost ready for its 1.0 release, stay tuned.
| The GH link: https://github.com/edgedb/edgedb/
|
| // Disclaimer: I'm a co-founder & CEO.
| assface wrote:
| > 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?
| 1st1 wrote:
| 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.
| assface wrote:
| Everything you said sounds like Britton-Lee's database.
| What is new?
| 1st1 wrote:
| 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.
| default-kramer wrote:
| 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.
| 1st1 wrote:
| Thanks for the kind words!
| divan wrote:
| 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.
| burlesona wrote:
| 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.
| RedCrowbar wrote:
| 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
| burlesona wrote:
| Just discovering EdgeDB. How does it handle graph queries
| (specifically, traversing joins across > 3 tables under the
| hood)?
| 1st1 wrote:
| 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.
| historyloop wrote:
| Question: why do you claim EdgeDB is a "relational" database
| when you can't actually do relational algebra with it? How do
| you join?
|
| Materialized edges (i.e. what you call "links") are not part of
| any relational model, it's a part of the graph model. You seem
| to have implemented a graph database, but possibly without the
| graph walking capabilities of graph databases.
| RedCrowbar wrote:
| 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.
| 1st1 wrote:
| 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.
| AlphaSite wrote:
| How would you represent a self join?
| RedCrowbar wrote:
| 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) }
| 1st1 wrote:
| Also feel free to play with EdgeDB in your browser with our
| interactive EdgeQL tutorial: https://www.edgedb.com/tutorial
| tgb wrote:
| 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"?
| okhuman wrote:
| Really nice 1st1 - congrats, all your resources look so clean.
| 1st1 wrote:
| Thanks! :)
| mirekrusin wrote:
| Is supporting MSSQL completely out of scope in not too distant
| future time frame?
| 1st1 wrote:
| Currently out of scope, sadly.
| p2hari wrote:
| Ok, this comes at a right time.. I was just starting a new
| project and considering Neo4j. I think it is unfair to compare it
| to Postgres but the EdgeQL make it look like the nested queries
| are easy to execute and comes with graphql support too. SO are
| there any pointers to how much production ready it is? How does
| it compare to raw SQL queries and nested queries? thanks. Also
| could not find much on authentication and authorizations. are
| there any pointers/
| 1st1 wrote:
| EdgeDB is _very_ close to be production ready. We will release
| 1.0 in a month or two and we 're based on Postgres, so the
| hardest part of storing the data reliably is there already.
|
| EdgeQL queries are typically way shorter than corresponding SQL
| equivalents. You can see comparisons and benchmarks here in
| this blog post: https://www.edgedb.com/blog/edgedb-1-0-alpha-1
|
| Authentication currently is very basic. We plan to have a
| relatively short release cycle, so in 3-4 months after 1.0
| we'll have more robust access control, including read/write
| policies of individual types and their properties/links.
| continuational wrote:
| Hmm 'select' before 'filter'. This is one of the things that's
| clunky in SQL; you have to select what you want before you know
| what you have.
| historyloop wrote:
| It's interesting that you know SELECT being first is clunky,
| without understanding why.
|
| SELECT in SQL is clunky because it comes before FROM and JOIN.
| Do you see FROM or JOIN anywhere here? No.
|
| The collections you're selecting from are literally written
| before the fields you select.
|
| The real WTF for me is this claims to be a relational database
| and you can't join seemingly.
| continuational wrote:
| That seems a bit snarky to me?
|
| In any case, the collection you're selecting from is
| presumably the filtered one, not the original one. Or am I
| misunderstanding the semantics?
| 1st1 wrote:
| I replied to another similar comment here:
| https://news.ycombinator.com/item?id=27795685
| aeaa3 wrote:
| The tech looks impressive and interesting.
|
| How will you guys make money? As a prospective user, what are the
| chances of being rethinkdb'd?
| 1st1 wrote:
| Cloud & enterprise solutions.
|
| There are a few reasons why RethinkDB failed; there's an
| excellent blog post written by the founder. I think there are
| many areas where we are quite different:
|
| - We are building on top of Postgres, so we are not investing
| too much time into the hardest technical problems like creating
| robust DB storage and query planning/execution engines.
|
| - Instead we focus our time on designing proper high level
| APIs, the EdgeQL language, migrations, and the DX.
|
| - Yet still, EdgeDB is a relational DB; it's strictly typed and
| fast. Which is still what the majority of companies want.
| anotherhue wrote:
| The actual website: https://www.edgedb.com/
|
| Apache 2 license: https://github.com/edgedb/edgedb
| historyloop wrote:
| > EdgeDB, a relational database with strongly typed schema
|
| Relational database without relational algebra wouldn't be
| useful, would it? So... uhmm. How do we join? There's no JOIN
| statement.
| 1st1 wrote:
| I replied in another comment:
| https://news.ycombinator.com/item?id=27795685
| your_challenger wrote:
| When will EdgeDB be production ready? Also will it handle large
| scale deployment with Fail-Over and Replication?
| 1st1 wrote:
| We plan to release 1.0 in a month or two. The upcoming beta 3
| (in 1-2 weeks) will be the last beta before the RC.
|
| That said, EdgeDB is already stable and solid thanks to the
| amazing Postgres that we're building it on top of. It's
| definitely ready now to play with and learn.
| 1st1 wrote:
| > Also will it handle large scale deployment with Fail-Over and
| Replication?
|
| Built-in support for that is coming, but it's already possible
| to run EdgeDB on top of Amazon RDS, for example. Ultimately
| EdgeDB is built on top of Postgres, so it will support
| replication and fail-over and many of the existing deployment
| strategies.
| rad_gruchalski wrote:
| What makes this product an "edge" database?
| no_circuit wrote:
| Presumably it refers to edges in an object graph [0]. EdgeDB
| seems to be currently deployed as a management, schema, and
| graph-to-sql translation layer for PostgreSQL.
|
| [0] https://www.edgedb.com/blog/edgedb-a-new-beginning#edgedb.
| 1st1 wrote:
| Correct!
| methyl wrote:
| > Note that this SQL query is not very efficient. An
| experienced developer would rewrite it to use subqueries
|
| Anyone care to explain why is that? I thought the query plan
| should be the same for JOINs and subqueries.
| RedCrowbar wrote:
| There is a difference in how large a set `array_agg` would
| need to process, since `LEFT JOIN` may produce a very
| sparse relation and NULLs still have to be scanned over.
| karmakaze wrote:
| It's not a database meant to run on the 'edge'. I'm guessing
| it's a graph database built on the PostgreSQL codebase.
|
| > EdgeDB is a relational database that stores and describes the
| data as strongly typed objects and relationships between them.
|
| > EdgeDB is built on top of PostgreSQL, inheriting all its core
| strengths: ACID compliance, performance, and reliability.
| mirekrusin wrote:
| Hey, after 1 minute of looking at it, it looks very interesting
| (composable etc), especially after reading recent sql rants like
| [0]
|
| [0] https://news.ycombinator.com/item?id=27791539
| 1st1 wrote:
| Thanks! You can also read our own rant here:
| https://www.edgedb.com/blog/we-can-do-better-than-sql (We can
| do better than SQL, it was on the front page of HN a couple of
| times).
| PostThisTooFast wrote:
| That's not a title. Come back when you can write something
| descriptive.
| xarope wrote:
| would you be able to use EdgeQL to introspect an existing
| postgresql database and run queries on it?
|
| Asking as I have a project ongoing where I don't really have the
| time to recreate everything in EdgeDB, but wouldn't mind spending
| a few hours to check how the query language works compared to
| SQL.
___________________________________________________________________
(page generated 2021-07-10 23:01 UTC)