RedCrowbar

9 ms·

31.
by RedCrowbar 4y ago
Demangling the schema into readable SQL schema is quite trivial already, as it's a fairly normal looking schema, except we use schema object ids in place of names (to simplify renaming). Turning EdgeQL into "readable" SQL is
32.
by RedCrowbar 4y ago
Yes, you can easily put OQL in the list of prior art EdgeQL was inspired by.
33.
by RedCrowbar 5y ago
That's correct. Prisma is an ORM with all the pros and cons of being one. EdgeDB, on the other hand, is a brand new graph-relational database server, built on PostgreSQL. ORMs have the ability to work with multiple RDBMS implementati
34.
by RedCrowbar 5y ago
Yes, the plan is to allow sending read-only queries to read replicas automatically. This isn’t implemented yet, but all the requisite pieces are there.
35.
by RedCrowbar 5y ago
There is no way to call UDF SQL (or PL/pgSQL) functions from EdgeDB, because there is no way to _define_ or manage them. The only place that is allowed to do this is the standard library (and, in the near future, extensions). We reali
36.
by RedCrowbar 5y ago
That’s exactly right.
37.
by RedCrowbar 5y ago
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 fr
38.
by RedCrowbar 5y ago
> Congrats on the milestone! Thanks! > Q: What are your plans for sharding / scale-out? Sharding is planned, though there is no set design yet, this area is in early research phase currently. Thanks for sharing your experience b
39.
by RedCrowbar 5y ago
It's usable and functional, because we use it in our CLI. It's WIP, because we haven't yet committed to an API, especially in async. Rust is a bit hard in that department :-)
40.
by RedCrowbar 5y ago
It's something we want to do at some point, but unlike Hasura, which operates on GraphQL which is conceptually much simpler and limited, EdgeQL would be much harder to fit onto a "pipelined polling" model that Hasura utilizes
41.
by RedCrowbar 5y ago
EdgeDB is graph-relational, not a pure graph database, and so the performance characteristics of traversing links are that of a relational JOIN. Which, of course, depends wholly on the size of each relation being joined. So, if you want t
42.
by RedCrowbar 5y ago
The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.
43.
by RedCrowbar 5y ago
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 implem
44.
by RedCrowbar 5y ago
> I’ll add to the positivity Thank you! > Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. We've not seen a major differenc
45.
by RedCrowbar 5y ago
The problem sounds like something that could be solved with a GIST index. EdgeDB doesn't yet have a way to specify the index type, though, mostly because we aren't sure what would be the best way to do it without things becoming
46.
by RedCrowbar 5y ago
We need to figure out the formal API and packaging format for extensions. We're working on it.
47.
by RedCrowbar 5y ago
It's a long story :-) https://www.edgedb.com/blog/building-a-production-database-i...
48.
by RedCrowbar 5y ago
Security policy will be part of the next release. See draft RFC [1], although note it's likely not going to be the final syntax. [1] https://github.com/edgedb/rfcs/blob/865bc48f4050ced99447bd77...
49.
by RedCrowbar 5y ago
We've got some benchmarks in an earlier blog post [1]. EdgeDB is designed to do its job validating and compiling your schema and queries and then get out of the way. In other words, once a query was first parsed and compiled, the cost
50.
by RedCrowbar 5y ago
We'll post some benchmarks against Hasura et al soon. "Faster than SQL" is, of course, relative and depends on "what SQL"? EdgeQL compiles into a single query that uses PostgreSQL-specific features. This is a guar
51.
by RedCrowbar 5y ago
We will run and support EdgeDB for you. Here's an expanded answer: https://github.com/edgedb/edgedb/discussions/3377
52.
by RedCrowbar 5y ago
Unfortunately, JSON aggregation destroys type information, so you can't reason about that your SQL query actually returns anymore.
53.
by RedCrowbar 5y ago
Also, this query is wrong because we want movies where Zendaya played, but _also_ other actors in order, possibly without Zendaya, so you really need to do the actors join twice.
54.
by RedCrowbar 5y ago
EdgeDB currently is. Graph-relational and EdgeQL are not.
55.
by RedCrowbar 5y ago
EdgeQL is designed to replace SQL, not graph query languages. Think of it as SQL getting a proper type system and GraphQL capabilities of reaching into deep relationships in an ergonomic way.
56.
by RedCrowbar 5y ago
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
57.
by RedCrowbar 5y ago
There are similarities with TAO and it's not a coincidence. Facebook engineers recognized that a better data abstraction and API was needed for productivity. EdgeDB follows the same logic. > would I have to care about the Postgres
58.
by RedCrowbar 5y ago
> It's the first time I hear about graph-relational DBs. This is unsurprising, because we just invented the term :-) > Is a graph-relational database something completely disjointed from a graph database? Graph-relational is stil
59.
by RedCrowbar 5y ago
Thank you!
60.
by RedCrowbar 5y ago
Because that only gives you actor names, not records, and also because arrays aren't a universal SQL feature.

More ›