261–270 of 332 posts
I love the feature set. Great work! Hard to believe this is the first major release. Are you guys planning to add C# client support?
Thank you. The feature set is indeed pretty deep. We are going to have a C# client for sure, but I don't have any ETA yet. FWIW you can interact with EdgeDB over HTTP!
How do you want to make money? Do you want to implement autoscale solution or how ?, this sounds increadibly in quite stagnate environment, good look I will give it a try
(And, is it likely to be possible to build it against standard interfaces like JDBC - or is it too different?)
It looks cool but am I mistaken that this is map reduce just consolidated into a query format? Very very cool for fun projects. As for work projects I'll wait for the Jepsen post.
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?
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 index…
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
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
[1] https://en.wikipedia.org/wiki/Conceptual_schema
[2] https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
Earlier quoted context omitted.
What do you mean by "too Postgres-specific"? Will you be supporting other DBs behind the EdgeDB interface in the future?
This is not something we plan to do in the near future, but it’s also not outside the realm of possibility. We picked Postgres because of its power, quality and unparalleled extensibility, but we are also very careful to not leak any implementation details into our interfaces.
> 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 what you're saying can both be true at the same time. Is EdgeDB tightly coupled to the implementation of PostgreSQL, or isn't it? Is there really a chance that EdgeDB could support other databases, or not really? I don't think there's anything wrong with the answers being "yes" and "no", respectively; that's actually what I'd expect. It would be more unusual to try to do this in an implementation-agnostic way.
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 su…
>> 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.…
I don't understand this claim. Can or does? This all just compiles down to SQL right?