Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

291–300 of 332 posts

Re: Show HN: EdgeDB 1.0

#291
Hi, looks really great! Thanks for this great piece of tech!

I have a question regarding the migrations, in the website you say it's safe to run them with automated flow, we know it uses Postgres under the hood and we know that sometimes migrations on large datasets can cause downtime in the database clusters. How do you handle them? I guess since you don't have a backing "users" table for a "User" model adding / removing fields is not actually happening the same way it happens in a normal relational database, thus it's not a blocking or resource consuming operation for you?

Re: Show HN: EdgeDB 1.0

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

> Although we'll be working on adding support for recursive queries to EdgeQL in the near future.

Is there a roadmap I can subscribe to somewhere?

Looking forward to trying this out!

Re: Show HN: EdgeDB 1.0

#294
post #233

Earlier quoted context omitted.

Does this mean that at the end it submits SQL queries to postgres? Or is the integration deeper?

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 Postgres b/c it only has one storage engine, but of course the separation still exists.

Re: Show HN: EdgeDB 1.0

#295

Earlier quoted context omitted.

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.

Well, the last update on the official ISO page https://www.iso.org/standard/76120.html is from November 2021. Does not look that dead to me. Standardization projects typically take awhile, specifically for something complicated as a query language spec.

The international committee (ISO/IEC JTC1 SC32 WG3 Database Languages) that is responsible for the database language standards SQL and GQL is pretty good at writing standards and not as good at taking about the work in progress. SC32 WG3 is developing two related standards to support property graphs:

1. SQL/PGQ (ISO/IEC JTC1 9075 part 16) -- This adds language to create property graph views on top of existing SQL tables and write property graph queries in a GRAPH_TABLE function in an SQL FROM statement.

2. GQL (ISO/IEC JTC1 39075 Database Language GQL) -- This is a full declarative property graph database language to create, maintain, and query graphs. This includes support for both descriptive and prescriptive schemas.

The Graph Pattern Matching language is identical between the two standards. For more details about GPM, see https://arxiv.org/abs/2112.06217

The ISO process has a defines series of milestones. I will spare you the details at the moment.

SQL/PGQ will start a Draft International Standard (DIS) ballot in July 2022 and so will be a published standard next year - 2023.

GQL will finish a Committee Draft (CD) ballot this month (February 2022) and should be ready for a DIS ballot in early 2023. However because GPM is shared between SQL/PGQ and GQL, the GQL Graph Pattern Matching will be stable when SQL/PGQ goes to DIS ballot.

For a little more detail on the GQL standards process and content, take a look at the talks from the LDBC TUC meeting August 2021: https://ldbcouncil.org/event/fourteenth-tuc-meeting/

Re: Show HN: EdgeDB 1.0

#296

Earlier quoted context omitted.

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

So, there is, basically, no way to work with Postgres directly, as well as installing EdgeDB with the use of the existing Postgres installation and its data, right? Feels like a Postgres is a prisoner of the EdgeDB :)

If you look at the code they used to have —postgres-dsn URL, now they changed it to —backend-dsn. If you go beyond the marketing, edgedb is a postgres connection pool+orm combined together with a query language (its a huge work in itself and commendable given it takes away many dependencies and provide a consistent developer experience). It’s leveraging postgresql server which is the true database providing ACID compliance.

Edgedb is more akin to hasura than to a database in traditional sense.

Re: Show HN: EdgeDB 1.0

#297
Arggh why is "order by" two space-separated words in their language?

If we're going to replace SQL the silly 1960s pseudo-English syntax is one of the things we want to get rid of, not retain.

Re: Show HN: EdgeDB 1.0

#299

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

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

I'm feeling very disappointed to see that you're using two space-separated words for "order by" in your language. Do "order" and "by" have meanings on their own in independence such that the meaning of "order by" arises naturally via their composition/conjunction? If not then surely it should be "orderby" in your language.

SQL definitely must be replaced, but the silly pseudo English syntax is one of the things we want to get rid of, not retain.

Re: Show HN: EdgeDB 1.0

#300
I didn't have a very in-depth look, but it looks like you try to solve a lot at once. So I could replace graphQL and permissions with just edgeDB? Sounds nice, but I'm sceptical.

And edit: why is there no Java/Kotlin client?

Post reply on HN