6 ms·

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 mar

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/ 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.

1st1 5y ago
>> 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. Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation. > > The true source of truth > I'm not sure why this means EdgeDB is better. <..> This section implies that EdgeDB's schema allows to specify a lot of meta / dynamically computed information in it. And soon your access control policies. Take a look at the work-in-progress RFC [2] [3] to see how this is more powerful, then say, Postgres' row level security. > > Not just a database server > It sounds like they have a solid client, which is awesome. Also lightweight connections to the DB so that you can have thousands of concurrent ones without load balancers, built-in schema migrations engine, and many other things. In fact we have so much that it's challenging what to even highlight in a blog post like the 1.0 announcement. > Cloud-ready database APIs > 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/ https://www.cockroachlabs.com/, or any of the tons of other database solutions. Not to pick on CockroachDB (they have an amazing product and company, we love them), but you should benchmark local install of Postgres and Cockroach to see yourself that scalability still has a significant cost in performance. [1] https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-server https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-s... [2] https://github.com/edgedb/rfcs/pull/49 https://github.com/edgedb/rfcs/pull/49 [3] https://github.com/edgedb/rfcs/pull/50/files https://github.com/edgedb/rfcs/pull/50/files
- Rapzid 5y ago
  > Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation. I don't understand this claim. Can or does? This all just compiles down to SQL right?

1st1 5y ago

>> 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. Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation. > > The true source of truth > I'm not sure why this means EdgeDB is better. <..> This section implies that EdgeDB's schema allows to specify a lot of meta / dynamically computed information in it. And soon your access control policies. Take a look at the work-in-progress RFC [2] [3] to see how this is more powerful, then say, Postgres' row level security. > > Not just a database server > It sounds like they have a solid client, which is awesome. Also lightweight connections to the DB so that you can have thousands of concurrent ones without load balancers, built-in schema migrations engine, and many other things. In fact we have so much that it's challenging what to even highlight in a blog post like the 1.0 announcement. > Cloud-ready database APIs > 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/ https://www.cockroachlabs.com/, or any of the tons of other database solutions. Not to pick on CockroachDB (they have an amazing product and company, we love them), but you should benchmark local install of Postgres and Cockroach to see yourself that scalability still has a significant cost in performance. [1] https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-server https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-s... [2] https://github.com/edgedb/rfcs/pull/49 https://github.com/edgedb/rfcs/pull/49 [3] https://github.com/edgedb/rfcs/pull/50/files https://github.com/edgedb/rfcs/pull/50/files

Rapzid 5y ago
> Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation. I don't understand this claim. Can or does? This all just compiles down to SQL right?