Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

81–90 of 332 posts

Re: Show HN: EdgeDB 1.0

#81
post #79

Can you front cockroachdb as it exposes a (mostly) postgresql api?

> 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

Re: Show HN: EdgeDB 1.0

#82
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?

Re: Show HN: EdgeDB 1.0

#83

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

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.

Re: Show HN: EdgeDB 1.0

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

Re: Show HN: EdgeDB 1.0

#85

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 relation…

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

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?

Re: Show HN: EdgeDB 1.0

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

EdgeDB is already postgres specific though.

Re: Show HN: EdgeDB 1.0

#87
post #84

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 2…

Thank you :)

Re: Show HN: EdgeDB 1.0

#88

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.

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.

Re: Show HN: EdgeDB 1.0

#89

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…

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?

Post reply on HN