Live data from Hacker News

EdgeDB 2.0

edgedb.com

61–70 of 150 posts

Re: EdgeDB 2.0

#61
post #55

Earlier quoted context omitted.

im hesitant to bet the horse against something this young. I can see the allure of it but there are just as many equal me-too ORMs on top of postgres. The idea of graph-relational is interesting but I'm not sure the pain points it describes (having to use JOIN) is enough to get me to use EdgeDB since it's not really an issue for most use cases unless you are doing very complex queries across dozens of tables. There w…

> There would also be some friction as to having to learn this new ORM language and having to rely on it completely whereas if we just stick to SQL and traditional ORM that is more popular (SQLAlchemy and SQLModel) You'll be surprised with how little time it takes to master EdgeQL and how much more you will be able to do with it compared to any ORM in existence or even raw SQL. Give it a try. Other than that -- use w…

will give it a whirl

Re: EdgeDB 2.0

#64
Congratulations with your release!

What is the current support level for `scale-out` clusters? I can find a thing or two about high availability [1] and a small set of transaction isolation levels [2], but I'm unable to find detailed information about locking mechanisms and cluster propagation. Is this a documentation problem, is it fully analogous to PostgreSQL or rather something that is still on the roadmap?

[1]: https://www.edgedb.com/docs/reference/backend_ha

[2]: https://www.edgedb.com/docs/stdlib/sys#type::sys::Transactio...

Re: EdgeDB 2.0

#65
post #25

Earlier quoted context omitted.

Yeah I really want to use EdgeDB, but I need full text search somehow. Options would be: 1. Somehow being able to query underlying postgresql database using traditional postgres FTS queries 2. Something like ZomboDB to bring the data into ElasticSearch or other like PGroonga 3. Ideally there would be some kind of FTS within EdgeDB so no need for another service

We'll be working on (3) soon and maybe (2) shortly after.

Right now, I don't see a way to choose an index type. For instance, while I don't need full text search (stemming, etc), simple trigram (gist_trgm_ops) would be desirable.

Re: EdgeDB 2.0

#66
post #60

Congratulation on the 2.0 release. EdgeDB looks awesome. However, I will not advocate using it for any of my clients unless there's a clear path to derisking its adoption. Like all new software products/services there's a significant risk of it becoming abandonware. I'd obviously want EdgeDB to succeed but how can one de-risk adopting it? Would it be possible to somehow "transpile" both queries and modeling scripts t…

Demangling the schema into readable SQL schema is quite trivial already, as it's a fairly normal looking schema, except we use schema object ids in place of names (to simplify renaming). Turning EdgeQL into "readable" SQL is probably also possible, depending on your definition of "readable" and the complexity of a query, though the current codegen does not prioritize SQL readability at all.

Re: EdgeDB 2.0

#67

Congratulations with your release! What is the current support level for `scale-out` clusters? I can find a thing or two about high availability [1] and a small set of transaction isolation levels [2], but I'm unable to find detailed information about locking mechanisms and cluster propagation. Is this a documentation problem, is it fully analogous to PostgreSQL or rather something that is still on the roadmap? [1]:…

That `sys::TransactionIsolation` doc is outdated, EdgeDB only supports the `Serializable` transaction isolation. See related discussion [1]

At this point EdgeDB supports Postgres HA passively, i.e. it will react to a failover event in your cluster via one of the documented mechanisms. Support for "active" cluster management is a planned feature too.

Finally, EdgeDB server itself is fully stateless and you can run multiple instances of it in front of the same Postgres cluster. Admittedly, we need to document this better.

[1] https://github.com/edgedb/edgedb/discussions/3466

Re: EdgeDB 2.0

#68

I barely ever used Postgres, but I’m curious - does Postgres support some sort of extensibility, so that something like EdgeDB could be just another plug-in that you could package into Postgres?

Postgres does have a very elaborate extension system, but it's unsuitable for something like EdgeDB, because we are fundamentally altering the database interface: EdgeQL vs SQL and a different client/server protocol.

Re: EdgeDB 2.0

#69
post #60

Congratulation on the 2.0 release. EdgeDB looks awesome. However, I will not advocate using it for any of my clients unless there's a clear path to derisking its adoption. Like all new software products/services there's a significant risk of it becoming abandonware. I'd obviously want EdgeDB to succeed but how can one de-risk adopting it? Would it be possible to somehow "transpile" both queries and modeling scripts t…

Demangling the schema into readable SQL schema is quite trivial already, as it's a fairly normal looking schema, except we use schema object ids in place of names (to simplify renaming). Turning EdgeQL into "readable" SQL is probably also possible, depending on your definition of "readable" and the complexity of a query, though the current codegen does not prioritize SQL readability at all.

How can one test this. Say I create a model and a slue of EdgeQL queries. How does one get the equivalent SQL (like a EdgeQL command to spit out the equivalent SQL). If this is not possible yet, could we at least have some examples on the EdgeDB website so as to have an idea?

Re: EdgeDB 2.0

#70
post #60

Congratulation on the 2.0 release. EdgeDB looks awesome. However, I will not advocate using it for any of my clients unless there's a clear path to derisking its adoption. Like all new software products/services there's a significant risk of it becoming abandonware. I'd obviously want EdgeDB to succeed but how can one de-risk adopting it? Would it be possible to somehow "transpile" both queries and modeling scripts t…

Demangling the schema into readable SQL schema is quite trivial already, as it's a fairly normal looking schema, except we use schema object ids in place of names (to simplify renaming). Turning EdgeQL into "readable" SQL is probably also possible, depending on your definition of "readable" and the complexity of a query, though the current codegen does not prioritize SQL readability at all.

That's great regarding the schema! The biggest risk mitigation factor in my estimation would be preserving the schema and the data. Re-writing queries would be annoying but doable if the schema is relatively sane.

edit: ps I love the direction y'all are heading. EdgeQL feels more like relational-algebra notation which I always felt fit better with modern programming languages.

Post reply on HN