7 ms·

What's a good way to develop a mental model about what's happening under the hood in EdgeDB? With SQL, I have a mental model of how things work under the hood.

by c4m 5y ago

What's a good way to develop a mental model about what's happening under the hood in EdgeDB? With SQL, I have a mental model of how things work under the hood. For instance, I think of each table as being stored separately on disk, containing "rows". And the rows are really just equally-sized data blocks that are laid out back to back. B+ trees, with leaf nodes that point to (or just are) the rows, are used for indexes. When I'm designing SQL schemas, I use this mental model to make guesses about performance. And when my queries are slow, I look at the execution plan. My question is, how can I develop a similar intuition about EdgeDB? Under the hood, how are types and links stored in Postgres? And if I'm having performance issues, can I see an execution plan?

ignoramous 5y ago
> What's a good way to develop a mental model about what's happening under the hood in EdgeDB? At the physical schema level [0] or at the conceptual schema level [1]? This answer from edgedb CTO might clear the latter up; https://news.ycombinator.com/item?id=30291538 https://news.ycombinator.com/item?id=30291538 As for the former, I guess it is the same as however Postgres (pg) chooses to represent the edge-db tables. EdgeDB (graph on pg) sounds like Timescale (timeseries on pg [2]). [0] https://en.wikipedia.org/wiki/Physical_schema https://en.wikipedia.org/wiki/Physical_schema [1] https://en.wikipedia.org/wiki/Conceptual_schema https://en.wikipedia.org/wiki/Conceptual_schema [2] https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
- c4m 5y ago
  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.
  - msully4321 5y ago
    I talked a bit about this in my release day talk (https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s 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
    - ignoramous 5y ago
      > So it's basically just translated to a relational database in normal form So... just an ORM ;)
      - colinmcd 5y ago
        In the sense that "object-relational mapping" is happening, then sure. The problem with the "ORM" term is that it comes loaded with a bunch of preconceptions that don't apply to EdgeDB. EdgeQL is a full query language with a standard library, grammar, and feature parity with SQL (almost). We've got a binary protocol. You use EdgeDB without ever needing to think about the layer beneath it—totally non-leaky. It's also not a library, which most people assume when you say "ORM".
        ignoramous 5y ago
        Having worked on databases, I am not the one to discount the effort that has gone into building EdgeDB. I was but jokingly referring to this: https://www.edgedb.com/_images/_blog/40fc2a2a81483bb0979c96d4e02b351b44196a18-940.webp https://www.edgedb.com/_images/_blog/40fc2a2a81483bb0979c96d... Btw, if you folks have time, then EdgeDB should consider penning posts like the ones timescale has been doing for 3 years or so, in its march to industry leadership.
    - c4m 5y ago
      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.

by c4m 5y ago

ignoramous 5y ago

> What's a good way to develop a mental model about what's happening under the hood in EdgeDB? At the physical schema level [0] or at the conceptual schema level [1]? This answer from edgedb CTO might clear the latter up; https://news.ycombinator.com/item?id=30291538 https://news.ycombinator.com/item?id=30291538 As for the former, I guess it is the same as however Postgres (pg) chooses to represent the edge-db tables. EdgeDB (graph on pg) sounds like Timescale (timeseries on pg [2]). [0] https://en.wikipedia.org/wiki/Physical_schema https://en.wikipedia.org/wiki/Physical_schema [1] https://en.wikipedia.org/wiki/Conceptual_schema https://en.wikipedia.org/wiki/Conceptual_schema [2] https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...

c4m 5y ago
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.
- msully4321 5y ago
  I talked a bit about this in my release day talk (https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s 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
  - ignoramous 5y ago
    > So it's basically just translated to a relational database in normal form So... just an ORM ;)
    - colinmcd 5y ago
      In the sense that "object-relational mapping" is happening, then sure. The problem with the "ORM" term is that it comes loaded with a bunch of preconceptions that don't apply to EdgeDB. EdgeQL is a full query language with a standard library, grammar, and feature parity with SQL (almost). We've got a binary protocol. You use EdgeDB without ever needing to think about the layer beneath it—totally non-leaky. It's also not a library, which most people assume when you say "ORM".
      - ignoramous 5y ago
        Having worked on databases, I am not the one to discount the effort that has gone into building EdgeDB. I was but jokingly referring to this: https://www.edgedb.com/_images/_blog/40fc2a2a81483bb0979c96d4e02b351b44196a18-940.webp https://www.edgedb.com/_images/_blog/40fc2a2a81483bb0979c96d... Btw, if you folks have time, then EdgeDB should consider penning posts like the ones timescale has been doing for 3 years or so, in its march to industry leadership.
  - c4m 5y ago
    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.