Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

61–70 of 332 posts

Re: Show HN: EdgeDB 1.0

#61
post #55

Earlier quoted context omitted.

(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-v…

put this straight onto your marketing page please!

Will do.

Re: Show HN: EdgeDB 1.0

#62
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

Re: Show HN: EdgeDB 1.0

#63
post #15

Is this a potential alternative to graph databases too? How does it compare to them?

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.

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.

Re: Show HN: EdgeDB 1.0

#64
post #62

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…

Because that only gives you actor names, not records, and also because arrays aren't a universal SQL feature.

Re: Show HN: EdgeDB 1.0

#65
post #45
post #33

Earlier quoted context omitted.

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…

Would be interesting to know how it fares against Prisma which is becoming pretty popular these days.

and to get updated benchmarks in general

Re: Show HN: EdgeDB 1.0

#66
post #5

EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4

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.

Re: Show HN: EdgeDB 1.0

#67
post #15

Earlier quoted context omitted.

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.

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…

maybe have a look at arangodb, I think their value proposition is something like you wrote.

Re: Show HN: EdgeDB 1.0

#68
post #44

Earlier quoted context omitted.

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.

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 :)

Thank you!

Re: Show HN: EdgeDB 1.0

#69
> 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.

Re: Show HN: EdgeDB 1.0

#70
post #66
post #5

EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4

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.

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.
Post reply on HN