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

311–320 of 332 posts

Re: Show HN: EdgeDB 1.0

#311

Post by colinmcd »

JadedBlueEyes wrote: post #309
electroly wrote: post #269

Earlier quoted context omitted.

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…

I think what they mean by this is that EdgeDB's query language should not be coupled to Postgres, but EdgeDB itself should use Postgres specific SQL features to maximise performance - so you couldn't drop in MariaDB without changing code in EdgeDB, but in theory you could write another backend that takes the same queries and uses MariaDB or MongoDB or something custom under the hood.

Exactly, implementation coupling vs interface coupling.

Re: Show HN: EdgeDB 1.0

#313

Post by emj »

torartc wrote: post #304
msully4321 wrote: post #209

Earlier quoted context omitted.

What colin said, or (in every terminal emulator I've used), ctrl-d to send end of file, which will close it.

That's interesting, I've always though ctrl-c would close things. I tried so many things like "quit" "exit" ctrl-c "help"

Ctrl-c cancels running processes, but not shells. When a process becomes a shell I can not say, but if make an infinite loop in the Python repl you can Ctrl-C that loop.

  $ python
  >>> while True:
  ...   pass
  ... 
  ^CTraceback (most recent call last):
    File "", line 1, in 
  KeyboardInterrupt

Re: Show HN: EdgeDB 1.0

#314

Post by redbar0n »

RedCrowbar wrote: post #97
dudus wrote: post #85

Earlier quoted context omitted.

It's the first time I hear about graph-relational DBs. I remember back in college learning about graph databases, but since I never touched one I don't remember much TBH. Is a graph-relational database something completely disjointed from a graph database? Or do they share some performance improvements to some use cases? Also does EdgeDB keep the advantages of a true graph database even being based on Postgres?

> 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 still relational, i.e. it's a relational model with extensions that make modeling and querying graph-like data easier. And in apps everything is graph-like (hence GraphQL etc). An important point…

>Pure graph databases, on the other hand, encode the assumption that data is actually _physically_ organized as a graph into their model and query languages.

What would be the benefit / disadvantage in each case?

Re: Show HN: EdgeDB 1.0

#315

Post by colinmcd »

the-alchemist wrote: post #312
1st1 wrote: post #5

EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4

What advantages/disadvantages does EdgeDB have over Dgraph.io?

Unfortunately DGraph is having some serious troubles as a company: https://discuss.dgraph.io/t/quitting-dgraph-labs/16702

Technically speaking though, using GraphQL as a data model is quite limiting: just basic scalar types and a handful of custom types implemented by DGraph (Polygon, etc). By contrast EdgeDB schemas support a much wider range of granular types, constraints, computed properties, link properties, etc.

Perhaps more importantly EdgeQL is a full query language with composable syntax, a standard library of functions and operators, for loops, primitive literal manipulations (e.g. string indexing and slicing), the ability to cast values to different types, subqueries, etc. Basically it's a complete query language contrast GraphQL is closer to an ORM in that it really only supports CRUD.

I think DQL is marginally more powerful though admittedly I'm not very familiar with it: https://dgraph.io/docs/get-started/

Re: Show HN: EdgeDB 1.0

#316

Post by shalabhc »

EdgeQL looks really nice. I do think this will be somewhat hard to sell because at small scales SQL and basic ORMs mostly work and have less lock-in. At large scales folks also want a lot more operational features like scaling out, control of the underlying schema for performance reasons, relaxing some constraints for horizontal sharding, and so on.

I think EdgeQL (and the data model) has potential for being a lot more than accessing the database. For example, you could have a distributed system use this data model across various typically replicated data stores - include all caches and "materialized views" of various kinds. Extend EdgeQL to define various caches and computed values from the core schema. Then you could use it to represent querying the same data but with different freshness. Now this becomes a compelling idea. Essentially it gives you a well defined way to declare and manage various computed values, laggy caches without having to manually implement all that coordination.

Re: Show HN: EdgeDB 1.0

#317

Post by shalabhc »

shalabhc wrote: post #316

EdgeQL looks really nice. I do think this will be somewhat hard to sell because at small scales SQL and basic ORMs mostly work and have less lock-in. At large scales folks also want a lot more operational features like scaling out, control of the underlying schema for performance reasons, relaxing some constraints for horizontal sharding, and so on. I think EdgeQL (and the data model) has potential for being a lot mo…

To add a specific example. A common pattern is 'put some objects in memcache' in front of the DB. Imagine if you can:

1. define a view representing the object fields you want to cache 2. define eviction and properties of the cache 3. use queries to query either the cache or the db

Specifically, do all of the above using edgeql and not have to write the cache consistency or serialization/deserialization logic.

Re: Show HN: EdgeDB 1.0

#318

Post by c4m »

msully4321 wrote: post #307
c4m wrote: post #305

Earlier 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

Thanks, this is helpful!

I think what I'm trying to understand is this: if I use EdgeDB in production, how often will I end up dropping down to the SQL level to debug things? If I'm trying to debug a slow query, can I do it at the EdgeDB level? Or will I have to open a PostgreSQL terminal, see how things are laid out there, run EXPLAINs, check the slow query log, and so on?

When I use ORMs, the answer to this is "pretty often". The ORM makes my application code cleaner, but I still need to have a complete understanding of the underlying SQL representation in order to ensure good performance and debug errors. I'm curious how that compares to using EdgeDB.

Re: Show HN: EdgeDB 1.0

#319

Post by thatwasunusual »

Trufa wrote: post #83
thatwasunusual wrote: post #69

> We should not continue wasting our productivity with a database API architecture from the last century. Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.

What a terrible attitude to have, that's truly the worst possible interpretation. How's that dissing anything? They are saying they have a good abstraction that will make you more productive. While it might not be, this is literally what makes software the amazing tool it is, building layers of abstraction that make you more productive. You seem to have gotten it all wrong, how could building something on top of SQL…

>> Show me _how_ you can beat SQL in performance

> It is literally a postgres instance underneath,

Exactly. So. Why? Someone created a database abstraction? God damn, that has almost never happened before! ;)

Re: Show HN: EdgeDB 1.0

#320

Post by thatwasunusual »

starik36 wrote: post #71
thatwasunusual wrote: post #69

> We should not continue wasting our productivity with a database API architecture from the last century. Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.

> Show me _how_ you can beat SQL Scroll down. They do exactly that.

>> Show me _how_ you can beat SQL

> Scroll down. They do exactly that.

Where?

Post reply on HN