Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

Post reply on HN
Print view View original

211–220 of 332 posts

Re: Show HN: EdgeDB 1.0

#211

Post by 1st1 »

0x202020 wrote: post #207

Poking a bit at the documentation, I see like/ilike but are there plans for text search/trigram capabilities? Recently I’ve been working with lots of different entities that have searchable properties and exploring searching across different elasticsearch indexes to do “JOIN” like operations but have been exploring Postgres (and related) solutions for better “JOIN” support out of the box

Yep, we have plans for that. We are exploring if it would be feasible to make it possible to plug-in external engines like elastic and make that integration totally automatic, enabled with a simple annotation in the schema.

Re: Show HN: EdgeDB 1.0

#212

Post by RedCrowbar »

eyelidlessness wrote: post #208
RedCrowbar wrote: post #201

Earlier quoted context omitted.

> 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 difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so…

It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses: - The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those. - The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected b…

The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.

Re: Show HN: EdgeDB 1.0

#213

Post by person3 »

This seems kind of cool, but honestly the benefits described don't really solve actual problems I've run into in development. The overall article reads like marketing talk and doesn't actually describe concretely why it's better than existing solutions. For something as core as a database I would expect more rigorous descriptions and benchmarks.

> We shall do better than SQL The EdgeQL language looks cool, and I'm sure querying via a graph structure makes certain problems easier in some use cases. However as much as people have complained about SQL, it's just so ubiquitous there needs to be a very good reason to switch away from it. Not having to write joins isn't really a good enough reason, in my opinion.

> The true source of truth I'm not sure why this means EdgeDB is better. Tons of applications use a traditional or cloud SQL database as the source of truth right now. This section seems to imply with microservices you no longer have a single source of truth. But if they're trying to say a microservice system should instead us a single common database that breaks separation of concerns and moves us into an annoying situation where you have a bunch of services communicating via a shared database.

> Not just a database server It sounds like they have a solid client, which is awesome.

> Cloud-ready database APIs > The vast scale of modern application deployments requires that inelastic computing resources are managed very carefully. Until cloud-native databases reach complete functional and performance parity with traditional databases, we will have to contend with the fact that the database is a scarce resource.

This used to be true, but is definitely no longer true. Cloud-native databases are everywhere and incredibly common. See any major cloud, https://www.cockroachlabs.com/, or any of the tons of other database solutions.

It's great to see a new database coming out - innovation in the space is super important. However this announcement reads like marketing speak, and is light on the details. When I see a new product I want to hear things like: - about how it scales - what the architecture is - why is it stable and trust-worth enough to put my data on - is it multi-node? How did they make it serializable? - how fast is it? Performance is super important.

Based on their website it seems like a thin skin over postgresql. If that's the case I'll just use postgresql. If it's a clustered new and advanced database, then I'll be wary about trusting it for anything real.

Re: Show HN: EdgeDB 1.0

#214

Post by eyelidlessness »

RedCrowbar wrote: post #201
eyelidlessness wrote: post #197

I’ll add to the positivity: this is the first time I’ve ever found a “we can do better than SQL” compelling. It’s easy to understand what it’s doing with a variety of known quantities. It solves a difficult problem elegantly. It has 100% overlap with the goals I want it to have. It’s designed to be usable with minimal fuss. It does really a good job of portraying itself as magic (it will be awesome to use) without po…

> 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 difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so…

Oof I meant to specifically address

> We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)).

You’ll likely not see anything noteworthy without specifically creating concurrency contention which specifically causes the kinds of pathological retry scenarios I mentioned. I’d be shocked if there isn’t at least a good starting point in either the Postgres test suite or Call Me Maybe. (Seriously though, I want to read Aphyr’s take on this project.)

Re: Show HN: EdgeDB 1.0

#215

Post by eyelidlessness »

RedCrowbar wrote: post #212
eyelidlessness wrote: post #208

Earlier quoted context omitted.

It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses: - The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those. - The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected b…

The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.

Awesome!

Re: Show HN: EdgeDB 1.0

#216

Post by nh2 »

Sounds pretty cool!

Questions:

1. What is the story for replication currently? Can I use EdgeDB with Posgres replication tools like Stolon or Patroni, running EdgeDB against the proxy they expose?

Or does EdgeDB plan/need to have its own replication?

Googling this, I found this previous HN post (https://news.ycombinator.com/item?id=19640689) saying:

> Tooling for that will be coming in the next few alpha releases.

2. "A builtin migration system that can reason and diff schemas automatically or interactively"

How do you deal with the fact that Posgres does not offer transactional DDL (e.g. ALTER TABLE)?

In our Posgres, we had to use advisory locks around migrations to avoid concurrent schema changes invoked by concurrently starting servers which run migration.

Re: Show HN: EdgeDB 1.0

#217

Post by RedCrowbar »

BeefWellington wrote: post #202
RedCrowbar wrote: post #23

Earlier quoted context omitted.

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

Hi! Thanks for taking the time to engage on HN. I have a couple of questions around this. Firstly, what happens to the performance when I have a sizeable resultset of set-valued data? I've seen similar ideas implemented in the past that look fine for the Movies and Actors or Books and Authors examples but fall apart badly when you query a number of fields (20+) that have sets within them, which can happen on say, a s…

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 to select the list of actors for _every_ movie in your database and there are lots of movies, it'd be a pretty expensive operation. If, on the other hand, you want to select some relationships on a handful of objects (or even just one), then it doesn't really matter that much how deep your link traversal is, because all of the steps would be fast index scans.

> How deep in the graph can I go,

As much as you want, though the path must be explicit, EdgeQL currently doesn't have any way to say "traverse link foo recursively".

Re: Show HN: EdgeDB 1.0

#218

Post by 0x202020 »

1st1 wrote: post #211
0x202020 wrote: post #207

Poking a bit at the documentation, I see like/ilike but are there plans for text search/trigram capabilities? Recently I’ve been working with lots of different entities that have searchable properties and exploring searching across different elasticsearch indexes to do “JOIN” like operations but have been exploring Postgres (and related) solutions for better “JOIN” support out of the box

Yep, we have plans for that. We are exploring if it would be feasible to make it possible to plug-in external engines like elastic and make that integration totally automatic, enabled with a simple annotation in the schema.

Even better then I would have thought, thanks! I’ve primarily dealt with Elasticsearch/Solr in my career, so jumping into the way searches work in Postgres with various native support and plugins is, interesting to say the least. Maybe I just need to break my Lucene roots

Re: Show HN: EdgeDB 1.0

#219

Post by RedCrowbar »

nicoburns wrote: post #200
RedCrowbar wrote: post #109

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

This sounds very similar to Hasura, which compiles graphQL down to SQL. Have you considered adding the subscription feature like they have?

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 to implement subs.

Re: Show HN: EdgeDB 1.0

#220

Post by RedCrowbar »

solairephantom wrote: post #186

Thank you for the monumental work you guys put into this! Looks very interesting, and something I would like to try out. One quick question - I see that you have a Rust client, however it's marked WIP, how usable is it in its current state? Any idea on a timeline of it becoming an official binding?

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 :-)
Post reply on HN