[HN Gopher] Show HN: EdgeDB 1.0
___________________________________________________________________
Show HN: EdgeDB 1.0
Author : colinmcd
Score : 347 points
Date : 2022-02-10 18:13 UTC (4 hours ago)
(HTM) web link (www.edgedb.com)
(TXT) w3m dump (www.edgedb.com)
| tluyben2 wrote:
| Congrats! Can I get the ebook as pdf somewhere?
| 1st1 wrote:
| An ebook with Easy EdgeDB (https://www.edgedb.com/easy-edgedb)?
| tluyben2 wrote:
| Yes, maybe I am blind (I am on mobile at the moment), but I
| would like the PDF of the book if you have it.
| smw wrote:
| Can you front cockroachdb as it exposes a (mostly) postgresql
| api?
| your_challenger wrote:
| > EdgeDB does not treat Postgres as a simple standard SQL
| store. The opposite is true. To realize the full potential of
| the graph-relational model and EdgeQL efficiently, we must
| squeeze every last bit of functionality out of PostgreSQL's
| implementation of SQL and its schema. Even then we've bumped
| into the ceiling quite a few times, and needed to send patches
| and bug reports upstream. That's also why EdgeDB currently
| requires PostgreSQL 13 or later.
|
| https://github.com/edgedb/edgedb/discussions/3403
| KwisaksHaderach wrote:
| _EdgeDB is built on an extension of the relational data model
| that we call the graph-relational model. This model completely
| eliminates the object-relational impedance mismatch while
| retaining the solid basis of and performance of the classic
| relational model._
|
| I don't see how can they retain the performance of the relational
| model when using graphs on top of PG unless they are using PG as
| storage k/v layer only.
| robertlagrant wrote:
| Why's that?
| 1st1 wrote:
| The key insight here is that we still have schema. We have
| high-level object types and a first-class notion of a
| "reference" - we call it "link". Our other extension of the
| relational model is that every "row" must have a unique ID.
| Both things combined implement a graph or your types and a
| graph of your data as it's stored in the underlying tables.
| Everything is strictly typed and efficient.
|
| But EdgeDB isn't ideal for storing loosely typed graph data,
| neo4j is built for that.
| 1st1 wrote:
| See also: https://news.ycombinator.com/item?id=30291538
| pier25 wrote:
| This looks really cool!
|
| Are you going to support some kind of subscriptions for realtime?
| 1st1 wrote:
| Potentially, but not in time for 2.0 (which should happen in
| just a few months).
| TheSpiciestDev wrote:
| I feel like a graph database is a solution to an issue I've faced
| (and, continue to face) and it may just be because that I haven't
| spun one up and tried or that the documentation/examples don't
| stick out. But could someone confirm my feeling? If my feeling is
| correct, I'd enjoy verifying it with EdgeDB or the like.
|
| My example/requirement: I have a user wanting to find best-
| matching blog posts. Every post is tagged with a given category.
| There could be 100+ categories in the blog system and a blog post
| could be tagged with any number of these system categories. A
| user wants to see all posts tagged with "angular", "nestjs",
| "cypress" and "nx". The resulting list should return and be
| sorted by the best matches, to those of least relevance. So,
| posts that include all four tags should be up top and as the user
| browses down the results, there are posts with less matching
| tags.
|
| What I've seen with SQL looks expensive, especially if you search
| with more and more tags. I may just not know what to search for
| though, re. SQL. Is there a query against a graph database that
| could accomplish this?
| contingencies wrote:
| _select posts.name as post, count(post_tags.id) as matches from
| posts,post_tags where post_tags.post=posts.id and post_tags.tag
| in ( "angular","nestjs","cypress","nx") group by post_tags.post
| order by matches desc;_ Test data @
| http://pratyeka.org/hn.sqlite3
| rmbyrro wrote:
| Thanks for posting this. Kind of comment that adds value to the
| discussion by illustrating how a piece of tech can or cannot be
| useful.
|
| I just happen to have a very similar requirement to yours and
| was also wondering.
| klohto wrote:
| Is it though? Simple IN with an ORDER BY on the same match will
| return the correct ranking. More info on ranking here
| https://www.postgresql.org/docs/current/textsearch-controls....
| d_watt wrote:
| Am I right in reading this as the parent comment envisioning
| a "post" table and a "tag" table, and you're suggest the
| "post" table just have a "tag" column?
| klohto wrote:
| I see just one table
|
| > Every post is tagged with a given category. There could
| be 100+ categories in the blog system and a blog post could
| be tagged with any number of these system categories.
|
| My point is, I don't see SQL query as expensive for this
| kind of use case. There are easy and native ways to do it.
|
| In case you would like a top notch performance, Redis might
| be a way to do it. Even a reverse-index would achieve great
| performance.
| thaumasiotes wrote:
| That's a standard many-to-many relationship that would
| normally be implemented by three tables:
| +---------+-------+---------+-------+-----------+
| | post_id | title | content | other | fields... |
| +--------+------+ | tag_id | name |
| +------------+---------+--------+ | tagging_id |
| post_id | tag_id |
|
| But it seems like the core of the request is still
| something like: SELECT post_id,
| count(1) AS count FROM taggings WHERE
| tag_id IN (3, 8, 255) GROUP BY post_id
| ORDER BY count DESC
|
| (off the top of my head; I haven't checked this for any
| kind of correctness)
|
| And I don't see why that query suffers as you add
| tags...?
|
| EDIT responding to below [HN believes I am a problem user
| who should only be allowed to make so many comments per
| day]:
|
| < that is pretty much what I meant by "I see just one
| table" as you don't need any joins
|
| Well, assuming you're doing this because a user is
| interacting with your site via some kind of web
| interface, you can set the interface up to deliver you
| tag_id values directly, but you'll still need to do a
| join with the posts table so you can present a list of
| posts back to the user instead of a list of internal
| post_id values.
|
| So I guess SELECT t.post_id, count(1)
| AS count, p.title, p.url FROM taggings t JOIN
| posts p ON t.post_id = p.post_id ...
| klohto wrote:
| Confusing but that is pretty much what I meant by "I see
| just one table" as you don't need any joins (atleast with
| the same design you outline)
| rmbyrro wrote:
| I'm currently investigating whether Redis Bloom [1] could be a
| good tool for similar requirement.
|
| [1] https://github.com/RedisBloom/RedisBloom
| FractalHQ wrote:
| I do these often with standard GraphQL queries, often over
| Postgres. Now I'm curious about the performance difference
| compared to an SQL ORDERBY or similar EdgeDB implementation!
| colinmcd wrote:
| EdgeDB employee here. I couldn't have asked for a better
| question to demonstrate the power of subqueries! Here's how I'd
| do this in EdgeQL: with tag_names :=
| {"angular", "nestjs", "cypress", "nx"}, select BlogPost {
| title, tag_names := .tags.name, match_count :=
| count((select .tags filter .name in tag_names)) }
| order by .match_count desc;
|
| Which would give you a result like this: [
| { title: 'All the frameworks!', tag_names:
| ['angular', 'nestjs', 'cypress', 'nx'], match_count:
| 4, }, { title: 'Nest + Cypress',
| tag_names: ['nestjs', 'cypress'], match_count: 2,
| }, { title: 'NX is cool',
| tag_names: ['nx'], match_count: 1, },
| ];
| rakibtg wrote:
| > EdgeDB is built on top of Postgres
|
| How it is a new database? Or an advanced orm?
| colinmcd wrote:
| We're working on a more comprehensive explanation of why EdgeDB
| isn't an ORM. Does EdgeDB do "object-relational mapping" under
| the hood -- absolutely. The reason we try to distance ourselves
| from the category of ORMs is that the term "ORM" comes with a
| big bag of preconceptions that don't apply here. EdgeDB has:
|
| - Full schema model with indexing, constraints, defaults,
| computed properties, stored procedures
|
| - A query language that replaces SQL. If there's something you
| can do in SQL that isn't possible in EdgeQL, it's a bug. Most
| ORMS provide some sort of language-specific API for writing
| queries and generating SQL under the hood--that's dramatically
| different than providing a new query language.
|
| - A full type system, grammar, set of functions and operators,
| etc. A set theoretic basis for all expressions in EdgeQL.
| https://www.edgedb.com/docs/edgeql/sets
|
| - A set of drivers for different languages that implement our
| binary protocol.
|
| EdgeDB is a new abstraction built on a lower-level abstraction:
| Postgres. Both indubitably fit any reasonable definition of
| "database".
| kurjam wrote:
| At the time of writing, docs have a large typo in them:
| https://www.edgedb.com/docs/clients/01_js/driver
|
| impoart * as edgedb from "edgedb";
| 1st1 wrote:
| Thank you!
| radicality wrote:
| I only glanced through this, but would you say there's some vague
| similarities (ignoring the distributed/caching aspects) to
| Facebook's TAO here? For example, as a user of this, would I have
| to care about the Postgres schema, or is that abstracted away
| from me?
|
| (Tao uses mysql and stores graph data as pretty much key/value
| pairs, and then a layer on top to query it)
| RedCrowbar wrote:
| There are similarities with TAO and it's not a coincidence.
| Facebook engineers recognized that a better data abstraction
| and API was needed for productivity. EdgeDB follows the same
| logic.
|
| > would I have to care about the Postgres schema, or is that
| abstracted away from me?
|
| EdgeDB takes care of everything for you. You wouldn't know it's
| Postgres underneath unless we told you.
| 1st1 wrote:
| We fully manage the underlying SQL schema for you, it's
| abstracted away (which will allow us to pull some tricks when
| we eventually introduce live schema migrations).
|
| I haven't worked at Facebook so I'm not super familiar with
| TAO, only heard about it from my friends. But sometimes I pitch
| EdgeDB as a database with which you don't need to build your
| _own_ TAO at _your_ company. we give you much more capabilities
| than a typical database.
| tailhook wrote:
| Hurray!
| sverhagen wrote:
| > the first open source, graph-relational database
|
| OrientDB?
| 1st1 wrote:
| As far as I'm aware OrientDB don't call themselves "graph-
| relational". In fact, they're positioning themselves as a
| multi-model NoSQL database. Where's EdgeDB positions itself as
| a relational database and a successor of SQL.
| waterbase wrote:
| Dgraph.io?
|
| How you guys compare yourself to dgraph database?
| 1st1 wrote:
| IIRC Dgraph is schemaless. EdgeDB is schema-first, which
| gives you type-safety and that amazing TypeScript query
| builder autocomplete experience :)
| josefrichter wrote:
| Is this a potential alternative to graph databases too? How does
| it compare to them?
| 1st1 wrote:
| If you use a graph database to store application data and you
| want a strict schema (and potentially improved performance),
| then YES.
|
| If you use a graph database to run graph algorithms on your
| data, then NO. Although we'll be working on adding support for
| recursive queries to EdgeQL in the near future.
| gazpacho wrote:
| Right on. I have been in the position before where I needed
| to do some graph-like queries (where I had to traverse
| several levels of joins with the number of joins unknown a
| priori) but at the same time this was an application storing
| structured data. I found myself in a tight spot between doing
| some really clunky Postgres stuff or going the graph DB
| route. I would have loved to have something that can be used
| like a relational DB 95% of the time but can still handle
| that 5% of graph-like queries with reasonable performance and
| complexity.
| josefrichter wrote:
| maybe have a look at arangodb, I think their value
| proposition is something like you wrote.
| gazpacho wrote:
| indeed I remember looking at them. this was years ago,
| and I'm no longer on the project though :)
| gazpacho wrote:
| this is still one of my favorite articles though:
| https://www.arangodb.com/learn/graphs/time-traveling-
| graph-d...
| solarmist wrote:
| Hell yeah. This is what I've wanted ever since I first learned
| about Apple's CoreData.
|
| This seems great. I have a highly interrelated data model (think
| parsed natural language text with annotations), and writing SQL
| to keep all of that data aligned and synced is a pain with an
| ORM.
|
| Am I right in imagining this works similarly to how Apple's
| CoreData does? It lets you build objects linked to each other but
| handles all of the joining and syncing of the data for you to
| keep the object model in mind.
|
| In the same vein will you be creating a Swift client?
| 1st1 wrote:
| I'm not too familiar with the CoreData API, but from a quick
| googling it seems like this is some sort of an ORM on top of
| SQLite.
|
| We position EdgeDB as a database server, not a library, partly
| because you can interact with it from different programming
| languages. But we design our client library with focus on API
| composability, check out our edgedb-js library for example:
| https://www.edgedb.com/docs/clients/01_js/index
|
| As for the Swift, it would be great to have it one day. I have
| a counter question: how many of you use Swift to write server-
| side logic?
| solarmist wrote:
| Right, but conceptually the way you interact with it is the
| same. I'm not trying to belittle what you've done. I'm in
| fact very excited about it.
|
| And EdgeDB is very needed because it's just an Apple library
| currently.
|
| Conceptually, my impression is that EdgeDb is relational
| tables (highly-typed) queried, combined, and modeled as nodes
| in a graph/tree. Is that conceptually correct?
|
| I don't, but I would like to if I could deploy Swift code to
| Azure. I love Swift as a language.
| danappelxx wrote:
| Swift has a family of Docker containers and an (admittedly
| modest) ecosystem of backend frameworks. You can definitely
| run it on Azure :)
| solarmist wrote:
| I know you can, but I'm talking about it being a 1st
| class citizen.
| thatwasunusual wrote:
| > We should not continue wasting our productivity with a database
| API architecture from the last century.
|
| Sorry, but dissing proven technology like this just makes me
| vomit. Show me _how_ you can beat SQL in performance and features
| on the frontpage, or I'm just happy to go along with what I
| already have.
| Trufa wrote:
| What a terrible attitude to have, that's truly the worst
| possible interpretation.
|
| How's that dissing anything? They are saying they have a good
| abstraction that will make you more productive. While it might
| not be, this is literally what makes software the amazing tool
| it is, building layers of abstraction that make you more
| productive.
|
| You seem to have gotten it all wrong, how could building
| something on top of SQL be dissing SQL? It's as much of a diss
| as C is a diss to assembly and so on.
|
| > Show me _how_ you can beat SQL in performance
|
| It is literally a postgres instance underneath, if edgedb is
| malleable enough, you don't need to beat anything, you'll have
| the query you want (sans edge cases and some minor overheads).
|
| > I'm just happy to go along with what I already have
|
| Go ahead bud, I'm pretty sure it won't be legally enforced to
| use any time soon so you're good to go.
|
| The fact that this low effort comments get upvoted in HN drives
| me mad, just the contrarian attitude will get you points no
| matter the depth or effort. You don't seem to have even read
| the landing page or tried it, maybe you did but your comment
| doesn't reflect that, this is the product of 4 years of effort
| by some devs that are trying to innovate, dissing it without
| even fully seem to understanding makes me want to vomit.
| imilk wrote:
| It's very frustrating that whenever a team is showing
| something new they've built to HN, so many of the top
| comments are focused some incredibly nitpicky, personal issue
| that somehow negates everything else about the project.
|
| It's an amazingly lazy and inconsiderate way to respond to
| people who've put a bunch of effort into building something.
| torartc wrote:
| Makes you want to vomit? That's a bit over the top.
| starik36 wrote:
| > Show me _how_ you can beat SQL
|
| Scroll down. They do exactly that.
| 1st1 wrote:
| Yeah, we also blogged about this extensively.
|
| Here are are some links:
|
| Pointed critique at SQL: [1]
|
| Benchmarks: [2] and [3]
|
| We'll be adding a dedicated benchmarks page to our website
| soon.
|
| [1] https://www.edgedb.com/blog/we-can-do-better-than-sql
|
| [2] https://www.edgedb.com/blog/edgedb-1-0-alpha-1
|
| [3] https://www.edgedb.com/blog/edgedb-1-0-alpha-2
| kall wrote:
| In [3] it says "we are assessing the code complexity and
| performance of a simple IMDb-like website built with
| Loopback, TypeORM, Sequelize, Prisma, Hasura, Postgraphile,
| raw SQL, and EdgeDB" but then it goes on to only explain
| the results of the classic ORMs but not hasura,
| postgraphile and prisma. Are the full results available
| somewhere?
|
| That classic ORMs are kinda slow is probably not a surprise
| to anyone, the others which either get to compile the full
| query or have a hand in controlling the schema are more
| interesting.
|
| They also seem more similar to your product, running as a
| server and managing the schema, so most worth comparing.
|
| Edit: The fact that "Raw SQL" ends up being a suboptimal
| query because of the node driver limitations, which then
| gives you "Way faster than even raw SQL!!!" graphs also
| leaves a weird taste. I guess if you are comparing
| programming language level solutions fair enough.
| RedCrowbar wrote:
| We'll post some benchmarks against Hasura et al soon.
|
| "Faster than SQL" is, of course, relative and depends on
| "what SQL"? EdgeQL compiles into a single query that uses
| PostgreSQL-specific features. This is a guarantee. No
| matter how large or complex your query is, if it
| compiles, it compiles into a single SQL query. Manually
| written or ORM-generated SQL tends to be "multi-query"
| due to the whole "standard SQL composes badly" story. And
| this matters, because if the roundtrip network latency
| between the client and the server is 10ms, EdgeQL will
| get you a response in ~10ms, whereas a multi-query
| approach will in (~10ms X <number-of-queries>) even if
| every individual query is super-quick to compute.
| why-el wrote:
| Strong reaction. In general we shouldn't discourage exploration
| and moving the needle forward. I actually agree with you that
| the language is somewhat stronger and the onus is on them to
| live up to it, but at the same time there is a lot of
| competition in this space (newer DBs) so nothing wrong with
| setting the bar high enough. :) They are specific with their
| use case (APIs), so that's excellent, as the core itself will
| not relinquish all the learnings of the "last century". ;)
| ei8ths wrote:
| how well does it scale?
| 1st1 wrote:
| EdgeDB co-founder Yury here. Ask me anything :)
|
| Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
| Dnguyen wrote:
| How do we migrate from existing Postgres database to EdgeDB?
| Can traditional app still access all the relational as before
| and new app access via EdgeDB? We're making use of existing
| environment and extending it with our own frontend. I would
| like to understand how I can mix legacy and new code.
| 1st1 wrote:
| We plan to introduce a tool for assisting migration from SQL
| databases, but at this very moment, the only way to migrate
| an existing app is to re-create your DB schema in EdgeDB and
| then write a script to import the data. EdgeDB _right now_ is
| definitely more geared towards starting new projects with it.
| infogulch wrote:
| Maybe if you move all data to be managed by EdgeDB, then
| create a separate "legacy" schema that just contains views &
| triggers that forwards queries and mutations to the EdgeDB
| database.
| j-pb wrote:
| Hey Yury, Cool stuff!
|
| How do you folks solve the large amount of joins that are the
| result of graph queries? Any worst-case-optimal multi-way-join
| secret sauce :D?
|
| Also, with DBs like Datomic competing in the same area, do you
| have an immutability/versioning story?
| 1st1 wrote:
| Thanks! The secret sauce is to pack nested shape queries into
| array_agg-ed SQL subquery. So we never select unnecessarily
| wide rows.
| kall wrote:
| Sounds like this is not dissimilar from the GraphQL-to-SQL
| compiler in Hasura, which also brings out surprising
| performance for wildly nested frontend queries.
| 1st1 wrote:
| Yeah, indeed, Hasura uses json_agg, which is similar but
| returns you a JSON string.
|
| We use array_agg, so we often avoid data serialization
| altogether. Our binary protocol just lets the data
| messages pass through with the original binary encoding.
| And because we fully control the schema, we can make all
| sorts of interesting optimizations, like implementing
| high-perf data codecs on the client side to unpack data
| fast.
| kall wrote:
| Yeah, that's an appealing idea, if there never even has
| to be any json.
|
| Hasura has the frontend safe API and strong authz going
| for it. Is that something you might also do, or are you
| focused on serving the backend? End-user row and column
| level authz gives me a lot of peace of mind when writing
| bigger queries.
| hyuuu wrote:
| do you have plans to integrate with prisma? it's almost a
| DIRECT translation of how the query is expressed in Prisma
| compared to edgedb. Googling quickly, it seems there is a
| ticket already. I wonder if this could be a low hanging fruit
| and a great growth channel since prisma is very popular.
|
| https://github.com/prisma/prisma/issues/10210
| 1st1 wrote:
| Not really, there's no point in using prisma with EdgeDB as
| our own query builder is more idiomatic for our product,
| faster, and we gape more capable.
|
| See also this reply by Colin:
| https://news.ycombinator.com/item?id=30293544
| torartc wrote:
| Any plans to have a gui?
| 1st1 wrote:
| Yes, it's in the works!
| boxed wrote:
| Is there an eta or public wip of a python query builder?
| 1st1 wrote:
| Our topmost priority now is launching a hosted version of the
| product, all hands on deck. Having a proper (and potentially
| fully type-safe) query builder for Python is literally the
| next to-do.
| mritchie712 wrote:
| Do you support columnar storage? i.e. to make analytics queries
| fast.
| 1st1 wrote:
| Not yet, but theoretically we might support something like
| Timescale in the future.
| sakopov wrote:
| I love the feature set. Great work! Hard to believe this is the
| first major release. Are you guys planning to add C# client
| support?
| 1st1 wrote:
| Thank you. The feature set is indeed pretty deep. We are going
| to have a C# client for sure, but I don't have any ETA yet.
| FWIW you can interact with EdgeDB over HTTP!
| ei8ths wrote:
| How well does it scale? Any benchmarks and performance metrics?
| spullara wrote:
| The query language reminds me a lot of JPA, which makes sense
| because this is essentially an ORM layer on top of Postgres.
| 1st1 wrote:
| Oh, EdgeDB is so much more than "basically an ORM layer". I
| suggest to scroll to the bottom of our home page edgedb.com and
| read the dedicated FAQ entry. I just don't want to restate the
| entire explanation here.
| sagarjs wrote:
| Looks great. Will try this out!
|
| Would a graphql API be part of your roadmap?
| RedCrowbar wrote:
| GraphQL is already supported:
| https://www.edgedb.com/docs/graphql/index
| jonking wrote:
| Why a new language? I can see and understand why and where graphs
| beat out SQL, but what does EdgeQL have over existing graph
| languages?
|
| Eg. vs Cypher or the likely-Cypher-compatible forthcoming GQL
| standard? https://www.gqlstandards.org/
| RedCrowbar wrote:
| EdgeQL is designed to replace SQL, not graph query languages.
| Think of it as SQL getting a proper type system and GraphQL
| capabilities of reaching into deep relationships in an
| ergonomic way.
| hobofan wrote:
| Forthcoming? Given that the last sign of live has been from 3
| years ago in a space with already little movement GQL seems to
| be most likely dead.
| hackandtrip wrote:
| I know benchmarking DB is very hard and pretty much nonsense, but
| do you have any idea / production use cases of EdgeDB at large
| scale? Did you see a performance drawback given from the higher
| abstraction, and the EdgeDB stateless client between the app and
| postgre?
| colinmcd wrote:
| EdgeDB employee here. We're beyond excited to finally publish a
| stable release of EdgeDB after 4 years of active development and
| 15 pre-releases. Happy to answer any questions on here!
| rmbyrro wrote:
| 4 years!? Wow, I can't imagine how you guys are feeling today,
| congrats and all the best to the project!
| 1st1 wrote:
| For the full story read another blog post:
| https://www.edgedb.com/blog/building-a-production-
| database-i... :)
| geenat wrote:
| These guys are from magic stack, they wrote the definitive async
| python postgres library, asyncpg. Very high quality library.
|
| Been keeping a close eye on Edge, had even considered it as a
| primary database, and probably will in the future!!
|
| As much as I adore the ergonomics improvements I really am more
| interested in the performance, replication, scalability story,
| with the likes of cockroach db reaching maturity in 2022.
|
| But as a postgres replacement in general, I would highly consider
| using edge.
| tragictrash wrote:
| Been searching for something just like this for my next
| moonshot project. Very excited!!!
| 1st1 wrote:
| Thank you :)
| say_it_as_it_is wrote:
| I think this work is absolutely commendable, but at the end of
| the day it's a database written in Python with Rust extensions
| sprinkled here and there. Is 1.0 your MVP?
| 1st1 wrote:
| EdgeDB is built on top of Postgres. The performance critical
| bits are either Python compiled to C with Cython or Rust, so
| there's almost no Python overhead.
|
| We perform quite favorably in benchmarks, see our old blog post
| with some:
| https://www.edgedb.com/blog/edgedb-1-0-alpha-2#results
|
| > Is 1.0 your MVP?
|
| EdgeDB is ready for production and is light years ahead of its
| first technical preview MVP release published a few years ago.
| pier25 wrote:
| Would be interesting to know how it fares against Prisma
| which is becoming pretty popular these days.
| gazpacho wrote:
| and to get updated benchmarks in general
| 1st1 wrote:
| Working on that!
| nikhilsimha wrote:
| Won't the functional variant read better than the SQL dialect
| movie_reviews .filter(_.actor.name.lowercase() ==
| "Zendaya") .groupBy(_.title, _.credit_order,
| avg(_.ratings)) .sortBy(_.credit_order) .take(5)
|
| vs. select Movie { title,
| rating := math::mean(.ratings.score) actors: {
| name } order by @credits_order limit 5,
| } filter "Zendaya" in .actors.name
| RedCrowbar wrote:
| It's a matter of taste. We decided to do a "looks like SQL +
| GraphQL" style because that's what most people are familiar
| when they think about a query language.
|
| That said, the functional variant is a likely way to represent
| EdgeQL in programming languages.
| 1st1 wrote:
| Keep in mind that EdgeQL is a query language that can be used
| from _any_ programming language (either over the official
| libraries, or over HTTP). Functional JS-inspired dialects aren
| 't appealing to everybody.
| udfalkso wrote:
| I like the flow of yours, but it doesn't capture the GraphQL
| piece. Where do you specify the nested limit and desired fields
| for the inner "actors"?
| quickthrower2 wrote:
| Nice. This seems so pragmatic - making something to make
| developers lives easier rather than doing something clever. I
| could see myself using this in personal projects. (My day job is
| heavily MS so wont be using it there)
| aljgz wrote:
| One thing that can facilitate adoption is a smooth path from a
| working software based on Postgresql to EdgeDB:
|
| We have a software that's a GraphQL interface to a database
| that's populated with a project (let's call it the indexer
| project) we do not control. It would be great if we could check
| the database schema for problems it might have to be used as an
| EdgeDB database. Then we would migrate our application to use
| EdgeDB, while the indexer keeps loading our database through
| direct interaction with PostgreSql.
| dawei67 wrote:
| This looks like a better prisma. Too bad its using postgresql. It
| will not scale. Do you plan to develop your own backend or
| support others one ?
| slx26 wrote:
| I don't have any strong opinion about it, but I have the same
| question: is it possible that in the long term the backend will
| be replaced by a custom one? And if not, what is the postgres
| backend bringing to the table that's difficult to replace? Sure
| there will be some friction between edge's model and the way it
| has to be internally expressed in postgres?
|
| Edit: oh, a relevant reply
| https://news.ycombinator.com/item?id=30293064
| xdfg13345 wrote:
| Typo in the post "and also retrive the list of top 5"
|
| should be retrieve
| 1st1 wrote:
| Good catch! A fix will be deployed in a couple of minutes :)
| joefigura wrote:
| Very exciting product, congratulations on the launch!
| 1st1 wrote:
| Thank you!
| gfodor wrote:
| Congrats - this looks really interesting, and this is coming from
| a person who generally ignores new shiny database news. Def will
| be checking this out!
| 1st1 wrote:
| Thank you! Please do and feel free to connect with us to
| discuss your experience :)
| gfodor wrote:
| if easy to answer: can this be used with eg AWS RDS? or is
| there something that couples the postgres engine tightly
| enough that's not doable?
| YohAsakura wrote:
| The live presentation is happening right now:
| https://www.youtube.com/watch?v=WRZ3o-NsU_4
|
| Very interested in what data engineers think about this project!
|
| I am not a developer, but the founders (including Yury Selivanov,
| Python Core Developer, see also https://github.com/MagicStack)
| and the fact that these people have been investing in the project
| for four years already, make me think that EdgeDB can be an
| important project for the database world!
| nknealk wrote:
| Can someone from EdgeDB explain why the SQL isn't as simple as
| what I have below? What am I missing? Why is that cross join
| lateral necessary: SELECT title,
| ARRAY_SLICE(ARRAY_AGG(movie_actors.name WITHIN GROUP (order by
| movie_actors.credits_order asc)),0,5)
| avg(movie_reviews.score) FROM movie JOIN movie_actors
| on (movie.id = movie_actors.movie_id) JOIN person on
| (movie_Actors.person_id = person.id) JOIN movie_reviews on
| (movie.id = movie_reviews.id) WHERE person.name like
| '%Zendaya%' group by title
| RedCrowbar wrote:
| Because that only gives you actor names, not records, and also
| because arrays aren't a universal SQL feature.
| nicoburns wrote:
| You can JSON_AGG to get whole records.
| [deleted]
| RedCrowbar wrote:
| Unfortunately, JSON aggregation destroys type information,
| so you can't reason about that your SQL query actually
| returns anymore.
| eatonphil wrote:
| EdgeDB is already postgres specific though.
| RedCrowbar wrote:
| EdgeDB currently is. Graph-relational and EdgeQL are not.
| SahAssar wrote:
| Until another db is graph-relational and can be queried
| via edgeql those are just as postgres-specific as arrays
| though, right?
| [deleted]
| RedCrowbar wrote:
| Also, this query is wrong because we want movies where Zendaya
| played, but _also_ other actors in order, possibly without
| Zendaya, so you really need to do the actors join twice.
| tzahifadida wrote:
| Orientdb is also sql like syntax graph database with way more
| traction. So this is not the first attempt at this type of
| databases.
| 1st1 wrote:
| I'll cite my other comment from this thread:
|
| OrientDB positions itself as a multi-model NoSQL database.
| Where's EdgeDB positions itself as a relational database and a
| successor of SQL.
| rahimiali wrote:
| Could someone explain what a graph-relational database is? I'm
| not able to extract a technical definition from the paragraph
| below:
|
| "What is a graph-relational database? EdgeDB is built on an
| extension of the relational data model that we call the graph-
| relational model. This model completely eliminates the object-
| relational impedance mismatch while retaining the solid basis of
| and performance of the classic relational model. This makes
| EdgeDB an ideal database for application development."
| RedCrowbar wrote:
| (EdgeDB CTO here)
|
| In a classic relational model everything is a tuple containing
| scalar values. Graph-relational extends the relational data
| model in three ways:
|
| - every relation always has a global immutable key independent
| of data (explicit autoincrement keys aren't needed)
|
| - this enables us to add a "reference type", which is
| essentially a pointer to some other record (i.e. a foreign key)
|
| - attributes can be set-valued, so you can have nested
| collections in queries and in your data model.
|
| This is what lets us do `Movie.actors.name` instead of a bunch
| of `JOINs`, because `actors` is declared as a set-valued
| reference type in the `Movie` relation.
| swyx wrote:
| put this straight onto your marketing page please!
| colinmcd wrote:
| Will do.
| [deleted]
| dudus wrote:
| It's the first time I hear about graph-relational DBs. I
| remember back in college learning about graph databases, but
| since I never touched one I don't remember much TBH.
|
| Is a graph-relational database something completely
| disjointed from a graph database? Or do they share some
| performance improvements to some use cases? Also does EdgeDB
| keep the advantages of a true graph database even being based
| on Postgres?
| RedCrowbar wrote:
| > It's the first time I hear about graph-relational DBs.
|
| This is unsurprising, because we just invented the term :-)
|
| > Is a graph-relational database something completely
| disjointed from a graph database?
|
| Graph-relational is still relational, i.e. it's a
| relational model with extensions that make modeling and
| querying graph-like data easier. And in apps everything is
| graph-like (hence GraphQL etc). An important point is that
| graph-relational, like relational is storage-agnostic, i.e.
| it makes no assumptions on how data is actually arranged on
| disk.
|
| Pure graph databases, on the other hand, encode the
| assumption that data is actually _physically_ organized as
| a graph into their model and query languages.
|
| I guess the word "graph" is simply too overloaded in
| computing.
| miohtama wrote:
| This is a nice example. How the data is stored physically?
| Does the model work for large datasets and when it could
| break down? What are optimal workloads? Do we still need to
| fiddle with indexing and such?
| RedCrowbar wrote:
| Data is stored relationally in Postgres in 3NF. References
| are indexed automatically, but you still need to index type
| properties if you use them in `filter`.
| samhw wrote:
| Wait, it stores the data in Postgres? So this is
| essentially a data model on Postgres?
|
| FWIW, I do think there's a space in the market for a
| _thin_ wrapper over Postgres (or MySQL) which would
| automate certain optimisations such as whether to index a
| particular table. It always struck me as perverse that
| that optimisation was delegated to the developer, when it
| 's no more subjective or application-specific than a
| thousand other automated optimisations the engine makes.
| I'd be really interested if your project covered that.
| RedCrowbar wrote:
| It's built on Postgres, but it isn't a _thin_ wrapper. We
| lean hard into Postgres query machinery and type system
| in order to pull off EdgeQL and graph-relational
| efficiently.
| samhw wrote:
| Ah, OK, interesting! I don't have an immediate use case
| personally, but I wish you guys the very best. Honestly,
| database space needs way more competition than it has at
| present.
|
| There are countless permutations of the choices that
| database designers face, so it's a shame there aren't
| mature products for more of them. I hope this particular
| permutation turns out to be a good one for lots of people
| :)
| RedCrowbar wrote:
| Thank you!
| ComodoHacker wrote:
| So it's basically an ORM over Postgres (and only Postgres)?
| colinmcd wrote:
| We're working on a more comprehensive explanation of why
| EdgeDB isn't an ORM. Does EdgeDB do "object-relational
| mapping" under the hood -- absolutely. The reason we try to
| distance ourselves from the category of ORMs is that the
| term "ORM" comes with a big bag of preconceptions that
| don't apply here.
|
| EdgeDB has:
|
| - Full schema model with indexing, constraints, defaults,
| computed properties, stored procedures
|
| - A query language that replaces SQL. If there's something
| you can do in SQL that isn't possible in EdgeQL, it's a
| bug.
|
| - The query language is backed by a full type system,
| grammar, set of functions and operators, etc.
|
| - A set of drivers for different languages that implement
| our binary protocol.
|
| By any definition, EdgeDB is a database. It's a new
| abstraction built on a lower-level abstraction: Postgres's
| query engine. Both abstractions indubitably fit any
| reasonable definition of "database".
|
| Basically: just because there's a declarative object-
| oriented schema doesn't mean this "is just an ORM" (unless
| your definition is quite pedantic).
| henryfjordan wrote:
| How exactly is EdgeDB run? Is it a separate process from
| Postgres, or some kind of plugin? Can I run it over an
| existing Postgres instance?
|
| If I build a DB Schema in EdgeDB, can I interact with the
| underlying Postgres instance using regular SQL?
| RedCrowbar wrote:
| It runs as a separate (stateless) process between the
| client and the PostgreSQL server. There was a talk about
| the details of the architecture on the live stream today:
| https://youtu.be/WRZ3o-NsU_4?t=5294
| gervwyk wrote:
| I've always wished for MongoDB to have a "deepFind", so that
| when I fetch a document, it will fetch the nested relations
| also instead of doing an aggression to do the lookup. Feel
| like if their objectID only included a collection name
| reference then somehow it should be possible. Perhaps a depth
| parameter would use be useful for more relational data.
| Congrats on the milestone! Will definitively have a look at
| edgeDB.
| spankalee wrote:
| This query language looks really nice!
|
| I wish GraphQL were more like this and considered built-in
| features like where clauses and cursors, instead of having to add
| those over the top with loose conventions.
| mstade wrote:
| I can't find anything in the docs on security. PostgreSQL had a
| pretty solid authorization story with row level security etc.
| Does EdgeDB provide any authorization mechanisms to ensure only
| data the user is entitled to is returned in queries?
| yewenjie wrote:
| I tried the beta around August last year. I struggled grokking it
| mostly because I had had very minimal experience with SQL - which
| it kind of assumed you already know the drawbacks of. However, I
| did like the idea very much.
|
| Looking forward to giving it another try soon!
| 1st1 wrote:
| Thank you! Working EdgeDB requires 0 SQL knowledge, you are not
| going to ever use it again.
|
| To quickly learn EdgeQL I recommend our online interactive in-
| browser tutorial: [1]
|
| We also have a book, it's called Easy EdgeDB, check it out
| here: [2]
|
| [1] https://www.edgedb.com/tutorial
|
| [2] https://www.edgedb.com/easy-edgedb
| nicoburns wrote:
| I suspect it was not specifically SQL knowledge they were
| lacking, but knowledge of how to work with relational
| databases.
| skybrian wrote:
| It's a good sales pitch, but it's not immediately clear what the
| terms are. I see that there is a company behind this, that
| there's also a Github repo, and it appears you can install
| something without paying. But is it entirely open source? If not,
| what are they selling? What kind of business is this?
| RedCrowbar wrote:
| We will run and support EdgeDB for you. Here's an expanded
| answer: https://github.com/edgedb/edgedb/discussions/3377
| colinmcd wrote:
| Everything is fully OSS: the database, our client libraries,
| our CLI. There's a company behind it (I'm an employee) which
| will make money with a cloud hosting platform, similar to
| Mongo. We're calling that EdgeDB Cloud and it's still under
| development. Though you can self-host too on any major cloud.
| [0]
|
| [0] https://www.edgedb.com/docs/guides/deployment/index
| totony wrote:
| EdgeQL seems like a custom graphQL. Any reasons you did not
| follow dgraph's DQL or graphQL-compatible language?
| https://dgraph.io/docs/get-started/
| 1st1 wrote:
| GraphQL doesn't have any syntax for expressions, like 1+1 is
| inexpressible with GraphQL. Once you add support for arbitrary
| expressions, functions, etc you start departing from GraphQL to
| something that looks surprisingly similar to EdgeQL :)
| likecarter wrote:
| I don't understand the benefit. It's just a query language on top
| of Postgres? It doesn't seem to have the performance
| characteristics of a graph database, while acting like it does.
| JOINS will still be expensive. You guys shouldn't use the word
| graph, misleading.
| dragosbulugean wrote:
| my thoughts exactly...
|
| a graph database is not useful because of its query language,
| it's useful because of its performance characteristics when
| bringing linked data -- it could never be performant on a
| Postgres backend.
| dudus wrote:
| I think the idea is to prove the query language more than
| deliver a database that has graph DB advantages. If they prove
| the language maybe they can implement a different backend. I'm
| just guessing here.
| 1st1 wrote:
| > If they prove the language maybe they can implement a
| different backend.
|
| This is very true and might happen in a far future.
| jimmar wrote:
| On https://www.edgedb.com/tutorial/basic-queries/objects, if I
| change "SELECT User.name;" to "SELECT User.Name;" the page
| crashes with, "Application error: a client-side exception has
| occurred." It crashes on Chrome and Edge.
| 1st1 wrote:
| We'll take a look, should be a quick fix.
| 1st1 wrote:
| Aaaaand... it's fixed!
| iddan wrote:
| This is so exciting. We can definitely do better than SQL in 2022
| and EdgeDB is a step in the right direction. Been using Prisma[0]
| in production in the past year and a half (which takes the same
| approach as EdgeDB but currently works for TypeScript and Golang)
| and I'm so happy. [0]: https://www.prisma.io/
| adevx wrote:
| Prisma + Typescript is such a productivity boon, auto
| completing all query options and database fields. And the
| results fully typed.
| colinmcd wrote:
| Prisma did a lot of things right, and we have a ton of respect
| for the team over there! At the end of the day, building a
| good, idiomatic API for doing CRUD operations is a hard
| problem, but building an entirely new query language that
| fundamentally solves some underlying design flaws and usability
| issues with SQL is a whole other level of difficulty. Since we
| got EdgeQL right, we were able to use it as the foundation of
| our query builder (we build the first version of the TypeScript
| QB in ~4 months) and it immediately leapfrogs all the major
| ORMs in power & expressibility. But that's only possible
| because the hard work of designing EdgeQL was already done.
|
| We'll be working on communicating how our query builder works
| and how it compares to ORMs in some of upcoming posts, stay
| tuned.
| vander_elst wrote:
| How does this compare against neo4j? When should I choose one
| instead of the other?
| 1st1 wrote:
| I replied to a similar comment here:
| https://news.ycombinator.com/item?id=30291290
| [deleted]
___________________________________________________________________
(page generated 2022-02-10 23:00 UTC)