71–80 of 332 posts
> 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.
Scroll down. They do exactly that.
Earlier quoted context omitted.
Right on. I have been in the position before where I needed to do some graph-like queries (where I had to traverse several levels of joins with the number of joins unknown a priori) but at the same time this was an application storing structured data. I found myself in a tight spot between doing some really clunky Postgres stuff or going the graph DB route. I would have loved to have something that can be used like a…
maybe have a look at arangodb, I think their value proposition is something like you wrote.
Earlier quoted context omitted.
Right on. I have been in the position before where I needed to do some graph-like queries (where I had to traverse several levels of joins with the number of joins unknown a priori) but at the same time this was an application storing structured data. I found myself in a tight spot between doing some really clunky Postgres stuff or going the graph DB route. I would have loved to have something that can be used like a…
maybe have a look at arangodb, I think their value proposition is something like you wrote.
We have a software that's a GraphQL interface to a database that's populated with a project (let's call it the indexer project) we do not control. It would be great if we could check the database schema for problems it might have to be used as an EdgeDB database. Then we would migrate our application to use EdgeDB, while the indexer keeps loading our database through direct interaction with PostgreSql.
EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
How do we migrate from existing Postgres database to EdgeDB? Can traditional app still access all the relational as before and new app access via EdgeDB? We're making use of existing environment and extending it with our own frontend. I would like to understand how I can mix legacy and new code.
Could someone explain what a graph-relational database is? I'm not able to extract a technical definition from the paragraph below: "What is a graph-relational database? EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relation…
(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…
> 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.
> 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.
Here are are some links:
Pointed critique at SQL: [1]
Benchmarks: [2] and [3]
We'll be adding a dedicated benchmarks page to our website soon.
[1] https://www.edgedb.com/blog/we-can-do-better-than-sql