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.
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.
Show HN: EdgeDB 1.0
301–310 of 332 posts
Re: Show HN: EdgeDB 1.0
#302ORMs work fine for relational data, until there's a lot of edge data on the joins. I looked at the docs on mobile and couldn't find an answer, how does EdgeDB handle data on joins? E.g. GraphQL "connection" types with edges.
Re: Show HN: EdgeDB 1.0
#303Earlier quoted context omitted.
We compile EdgeQL queries into SQL currently, because it makes the architecture simpler and less us run on unmodifed Postgres, but conceptually nothing stops us from targeting the query planner directly via an extension or an alternative frontend that consumes EdgeQL IR direclty.
Ah, this is interesting: so Postgres is effectively a 'backend' for you, in much the same way that e.g. InnoDB is a backend for MySQL[0]? And you - or hypothetically the end user - could change the backend, e.g. to Cockroach for better horizontal scalability, while trusting that EdgeDB will only rely on Postgres's public API at least in meeting its own public API/contract? [0] It's hard to make that analogy with Post…
Re: Show HN: EdgeDB 1.0
#304Earlier quoted context omitted.
Dumb question, how do you exit the shell? I feel like I've scoured the docs and can't find it.
What colin said, or (in every terminal emulator I've used), ctrl-d to send end of file, which will close it.
Re: Show HN: EdgeDB 1.0
#305What's a good way to develop a mental model about what's happening under the hood in EdgeDB? With SQL, I have a mental model of how things work under the hood. For instance, I think of each table as being stored separately on disk, containing "rows". And the rows are really just equally-sized data blocks that are laid out back to back. B+ trees, with leaf nodes that point to (or just are) the rows, are used for index…
> What's a good way to develop a mental model about what's happening under the hood in EdgeDB? At the physical schema level [0] or at the conceptual schema level [1]? This answer from edgedb CTO might clear the latter up; https://news.ycombinator.com/item?id=30291538 As for the former, I guess it is the same as however Postgres (pg) chooses to represent the edge-db tables. EdgeDB (graph on pg) sounds like Timescale (…
Re: Show HN: EdgeDB 1.0
#306I started a container and connected it, but instantly got an email from heroku telling me i had 19500 of my 10000 rows, and 215 tables. Not really any hobby-project viable priced hosting options in their documentation.
Re: Show HN: EdgeDB 1.0
#307Earlier quoted context omitted.
> What's a good way to develop a mental model about what's happening under the hood in EdgeDB? At the physical schema level [0] or at the conceptual schema level [1]? This answer from edgedb CTO might clear the latter up; https://news.ycombinator.com/item?id=30291538 As for the former, I guess it is the same as however Postgres (pg) chooses to represent the edge-db tables. EdgeDB (graph on pg) sounds like Timescale (…
I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
* Every edgedb type has a postgres table
* "single" properties and links are stored as columns in that table (links as the uuid of the target)
* "multi" properties/links are stored as a link table
So it's basically just translated to a relational database in normal form
Re: Show HN: EdgeDB 1.0
#308Earlier quoted context omitted.
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_…
Do I understand this correctly in that if the list goes on, it will also show posts with unrelated tags in tag_names? As the filter is only applied to match_count? So to only get blog posts with matching tags we would need to add a filter „match_count > 0“, right? Update: I am very excited about EdgeDB :)
with tag_names := {"angular", "nestjs", "cypress", "nx"},
select BlogPost {
title,
tag_names := .tags.name,
match_count := count((select .tags filter .name in tag_names))
}
filter .match_count > 0
order by .match_count desc;Re: Show HN: EdgeDB 1.0
#309Earlier quoted context omitted.
This is not something we plan to do in the near future, but it’s also not outside the realm of possibility. We picked Postgres because of its power, quality and unparalleled extensibility, but we are also very careful to not leak any implementation details into our interfaces.
I'm curious how this squares up with what someone linked elsewhere: https://github.com/edgedb/edgedb/discussions/3403 > 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. I don't see how this and…
Re: Show HN: EdgeDB 1.0
#310Earlier quoted context omitted.
I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
I talked a bit about this in my release day talk ( https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s ), but: * Every edgedb type has a postgres table * "single" properties and links are stored as columns in that table (links as the uuid of the target) * "multi" properties/links are stored as a link table So it's basically just translated to a relational database in normal form
So... just an ORM ;)