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?
Show HN: EdgeDB 1.0
291–300 of 332 posts
Re: Show HN: EdgeDB 1.0
#292Is 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.
Is there a roadmap I can subscribe to somewhere?
Looking forward to trying this out!
Re: Show HN: EdgeDB 1.0
#293Re: Show HN: EdgeDB 1.0
#294Earlier 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.
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
#295Earlier 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.
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
#296Earlier 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 :)
Edgedb is more akin to hasura than to a database in traditional sense.
Re: Show HN: EdgeDB 1.0
#297If 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
#298Re: Show HN: EdgeDB 1.0
#299I 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_…
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
#300And edit: why is there no Java/Kotlin client?