EdgeDB 2.0(edgedb.com)
edgedb.com
EdgeDB 2.0
https://www.edgedb.com/blog/edgedb-2-0
149 comments
I just took a look at the quickstart guide. The way the code snippets are implemented is gorgeous. They are syntax highlighted, are formatted/indented exactly as they would be in the terminal, line breaks are indented correctly but css is used to make them easily copy/pastable without including any line numbers/indentation characters. Such a delight. Such focus on details. Makes me really confident in the rest of the project.
Finally somebody compliments that! Jokes aside, thank you!
I agree. There was a small glitch where the field year was defined as release_year at the beginning. I wanted to submit a PR but it was already fixed on github version, just not published yet.
TIL about user-select:none;
That's useful, I hate copying code snippets alongside line numbers and other weirdness
That's useful, I hate copying code snippets alongside line numbers and other weirdness
We use it throughout our UI in all interactive elements. It's super annoying when, say, a button or a navigation element gets accidentally selected for no reason.
It's great... Until people start abusing it as an ineffective copy protection mechanism.
people can already do that with javascript anyway
I had no idea what EdgeDB is/was so I took a look at the site. The first thing that stood out was a typo (that's instead of that). It's since been fixed, but I had to chuckle at attention to detail.
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 to readable SQL? That way, worste case scenario one may fall back on Postgresql without loosing most of previous work.
Let me be clear. I really like EdgeDB and obviously want the best for and you guys but I do not think I'm alone in thinking that we need a clear, easy and verifiable way to fallback to Posgresql if/when needed.
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.
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.
Thanks!
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?
You can run the server in foreground [1] with `env EDGEDB_DEBUG_EDGEQL_COMPILE_SQL_TEXT=1` and observe emitted SQL.
[1] edgedb instance start --auto-restart --foreground -I <your instance>
[1] edgedb instance start --auto-restart --foreground -I <your instance>
[deleted]
I'm working on a npm package [1] that "transpile" from a syntax inspired by edgedb into raw sql. The generated sql and be used with original database, without additional running process.
I've implemented select columns, join tables and where statements. Still having more to work on (e.g. order by, group by, aggregate function, and more important, the readme)
[1] https://github.com/beenotung/better-sql
I've implemented select columns, join tables and where statements. Still having more to work on (e.g. order by, group by, aggregate function, and more important, the readme)
[1] https://github.com/beenotung/better-sql
I want to build local first software backed by EdgeDB. Similar to these tools:
- https://replicache.dev
- https://github.com/tantaman/conflict-free-sqlite
- https://aphrodite.sh
I wonder if EdgeDB provides any utilities to make this already perhaps? Or community has to build some kind of CRDT software that builds on top of EdgeDB that will do local syncing? Maybe that's planned to be tackled for 3.0?
- https://replicache.dev
- https://github.com/tantaman/conflict-free-sqlite
- https://aphrodite.sh
I wonder if EdgeDB provides any utilities to make this already perhaps? Or community has to build some kind of CRDT software that builds on top of EdgeDB that will do local syncing? Maybe that's planned to be tackled for 3.0?
Curious if you've taken a look at ChiselStrike (disclaimer: founder here)
ChiselStrike translates typescript to sql transparently (https://blog.chiselstrike.com/my-other-database-is-a-compile...) and works well with Replicache (https://blog.chiselstrike.com/offline-data-access-a-dream-co...)
We don't have that yet. Maybe it will be possible to bootstrap EdgeDB to run on top of SQLite, but that will be a ton of work and limit the schema/language. Nothing prevents you from just running EdgeDB or even bundling in your app except packaging that can get a bit hairy.
Isn't EdgeDB a python program? I fear python packaging - especially inside a browser or Android device.
It's a mix of Python, C, Rust, Cython, etc. It's fully safe-contained though, the fact that there's some Python inside is an implementation detail, you'll never know that as a user.
but, I would know as an app builder if I was running EdgeDB against a local datastore on a user's device, right?
Couchbase-lite seems to do what you're asking. It's backed onto sqlite. It's more sync based than crdt based afaict.
Adding ObjectBox to the list.
https://objectbox.io/
https://objectbox.io/
Unfortunately ObjectBox has a proprietary core, which is unfortunate as I'd love to modify it for experimental uses.
Any questions on ObjectBox, happy to answer. We believe (and get the feedback) we've made the APIs very intuitive :)
Shameless plug of my post on the one-year experience with EdgeDB:
https://divan.dev/posts/edgedb/
It's a great one, Ivan, thank you for writing it! :)
EdgeDB co-founder and CEO here. Ask me anything.
We are streaming EdgeDB 2.0 launch event right now, join here: https://www.youtube.com/watch?v=1jloGHV31Ow
We are streaming EdgeDB 2.0 launch event right now, join here: https://www.youtube.com/watch?v=1jloGHV31Ow
Congrats on the launch!
How do folks deal with the latency of not being able to run EdgeDB on the same server as their managed Postgres service (e.g. RDS)?
Full disclosure: I work on SpiceDB[0] which is a fine-grained permissions database. SpiceDB can also be backed by Postgres, but we form a distributed cache with our database instances so that trips to the datastore (e.g. Postgres) are avoided at all costs.
[0]: https://github.com/authzed/spicedb
How do folks deal with the latency of not being able to run EdgeDB on the same server as their managed Postgres service (e.g. RDS)?
Full disclosure: I work on SpiceDB[0] which is a fine-grained permissions database. SpiceDB can also be backed by Postgres, but we form a distributed cache with our database instances so that trips to the datastore (e.g. Postgres) are avoided at all costs.
[0]: https://github.com/authzed/spicedb
EdgeDB is super efficient in its communication with the postgres backend. Most of the time there's only one roundtrip for any query. So chances are, because of how you can pipeline many operations in EdgeQL into one single query, the latency is still going to be far better than a typical ORM+Postgres combination.
That said, we're working on our cloud, all hands on deck. There you wouldn't have any additional latency.
That said, we're working on our cloud, all hands on deck. There you wouldn't have any additional latency.
EdgeDB is looking like a dream db (with batteries included) to me, congrats on the launch!
I wonder if you might wanna join efforts on building your cloud offer with guys at https://neon.tech/ (i'm not affiliated, but I'm waiting for your cloud offering)
I wonder if you might wanna join efforts on building your cloud offer with guys at https://neon.tech/ (i'm not affiliated, but I'm waiting for your cloud offering)
We'll be closely looking an Neon and we know the team. There are some related things that we have to figure out before investing time into the integration.
In a recent post here on HN, Shipping Multi-Tenant SaaS Using Postgres Row-Level Security [1], comments indicated gaps in PostgreSQL's RLS implementation, specifically for views (at least until PG15). I suppose EdgeQL is compiled directly to full SQL statements and doesn't utilize views, so this issue in particular may not affect EdgeDB.
Does EdgeDB implement object-level access control on top of PostgreSQL's RLS? Have you run into any tricky edge cases? Did you have any particular inspirations for the design (e.g. Google Zanzibar)?
[1]: https://news.ycombinator.com/item?id=32241820
Does EdgeDB implement object-level access control on top of PostgreSQL's RLS? Have you run into any tricky edge cases? Did you have any particular inspirations for the design (e.g. Google Zanzibar)?
[1]: https://news.ycombinator.com/item?id=32241820
EdgeDB does not use Postgres RLS, access rules are injected into every query by the query compiler instead. This side-steps the RLS gotchas and limitations (RLS does not allow aggregates in rules, EdgeDB does), but also yields somewhat better query performance.
Have you considered cockroachdb as a backend database? I imagine that although the postgresql emulation of cockroachdb isn't 100% complete, the availability story of cockroachdb is miles ahead of postgresql, so perhaps it might be worth whatever adaptations are necessary.
Alas, we have to wait until CockroachDB becomes a bit more capable SQL-wise. I gave a more elaborate answer in https://github.com/edgedb/edgedb/discussions/3403.
> To realize the full potential of ... EdgeQL efficiently, we must squeeze every last bit of functionality out of PostgreSQL's implementation
> That said, EdgeDB, the implementation, and EdgeQL, the language and the model, are different, and we encourage research into alternative EdgeQL implementations. We'll be releasing the formal EdgeQL spec and the graph-relational model whitepaper to make this easier.
Has the mentioned spec and model whitepaper been released?
> That said, EdgeDB, the implementation, and EdgeQL, the language and the model, are different, and we encourage research into alternative EdgeQL implementations. We'll be releasing the formal EdgeQL spec and the graph-relational model whitepaper to make this easier.
Has the mentioned spec and model whitepaper been released?
Not yet. Our reference documentation is extremely thorough though, an implementor of an alternative backend should be able to use it.
If I have an existing Postgres database (on RDS) can I use EdgeDB to query it? Are there tools to generate a schema from an existing Postgres schema? Or is this mainly for green field projects without an existing database?
EdgeDB is very particular about how the underlying data is organized, so you can't put it in front of an existing database. Importing schemas and data is another story which we're working on.
I asked on Twitter but I'll ask again here :)
What's the current approach for triggers, subscriptions, etc?
Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?
What's the current approach for triggers, subscriptions, etc?
Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?
Triggers might make it to 3.0, but we'll have to write an RFC and see if it's doable in the timeframe we have for it and given the other higher priority items on the ToDo list. We contemplated mentioning them in the 2.0 blog post but decided not to over-promise :)
Regarding subscriptions -- polling is the current best (and unfortunate) answer. We'll keep researching this area.
> Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?
Not yet. We plan to eventually allow read-only SQL queries to go through EdgeDB for plugging existing analytical tools/BI. But the demand from the community for this feature has been so far pretty low.
Regarding subscriptions -- polling is the current best (and unfortunate) answer. We'll keep researching this area.
> Can you perform raw SQL queries through your client or do apps still need to use a separate PG client for that?
Not yet. We plan to eventually allow read-only SQL queries to go through EdgeDB for plugging existing analytical tools/BI. But the demand from the community for this feature has been so far pretty low.
> Not yet. We plan to eventually allow read-only SQL queries to go through EdgeDB for plugging existing analytical tools/BI. But the demand from the community for this feature has been so far pretty low.
It's interesting you say this. This is the reason I passed on EdgeDB. If it was additive to SQL (you can use EdgeDB optionally) that would be great. Im not sure people would ask for it, but given the option everyone would use it.
It's interesting you say this. This is the reason I passed on EdgeDB. If it was additive to SQL (you can use EdgeDB optionally) that would be great. Im not sure people would ask for it, but given the option everyone would use it.
> But the demand from the community for this feature has been so far pretty low.
Makes sense since most read queries can (probably) be performed already with EdgeDB.
But my point about executing raw SQL was regarding having an escape hatch for features like listen/notify, etc.
I guess the solution is that for now apps will need a second PG client. Do you anticipate any problems with that approach?
Makes sense since most read queries can (probably) be performed already with EdgeDB.
But my point about executing raw SQL was regarding having an escape hatch for features like listen/notify, etc.
I guess the solution is that for now apps will need a second PG client. Do you anticipate any problems with that approach?
Where can I find instructions on how to build EdgeDB from source? Also, what is the difference between https://github.com/edgedb/edgedb and https://github.com/edgedb/edgedb-cli?
Build instructions: https://www.edgedb.com/docs/guides/contributing
Repos: the first repo is the database itself; the second is our CLI -- tools for migrations, dump/restore, repl, etc.
Repos: the first repo is the database itself; the second is our CLI -- tools for migrations, dump/restore, repl, etc.
congrats on this milestone.
I’m currently using a graph database (dgraph) mostly so I can easily query complex relationships), and I’m wondering whether EdgeDB has similar performance due to how it stores data?
my understanding of EdgeDb is that it stores everything in a single table, and there’s an underlying graph structure. does this give added performance on complex queries?in other words, does EdgeDB perform complex queries involving multiple relationships better than an equivalent complex Postgres JOIN query? how does the performance compare to the average graph database for queries involving complex relationships? has it been performance tested on complex queries?
I’m currently using a graph database (dgraph) mostly so I can easily query complex relationships), and I’m wondering whether EdgeDB has similar performance due to how it stores data?
my understanding of EdgeDb is that it stores everything in a single table, and there’s an underlying graph structure. does this give added performance on complex queries?in other words, does EdgeDB perform complex queries involving multiple relationships better than an equivalent complex Postgres JOIN query? how does the performance compare to the average graph database for queries involving complex relationships? has it been performance tested on complex queries?
EdgeDB stores data in a fairly normalized table layout, where every object type corresponds to a physical table.
The performance of deep hierarchical queries with EdgeQL will be better than SQL with joins because with joins you'd have an unnecessarily wide denormalized set of rows. EdgeDB instead aggregates data in nested arrays via subqueries. The performance is great.
https://github.com/edgedb/imdbench
The performance of deep hierarchical queries with EdgeQL will be better than SQL with joins because with joins you'd have an unnecessarily wide denormalized set of rows. EdgeDB instead aggregates data in nested arrays via subqueries. The performance is great.
https://github.com/edgedb/imdbench
thanks!
For the rust client, is there any plan to introduce a query builder and/or generated typing? Currently it feels very sqlx like which is ok for some, but I prefer to have a bit of typing.
Yes, we want to have query builders for all languages. If you love Rust and have time to contribute we'd love some help. Figuring out a great QB Rust API might take some time.
[deleted]
Will edgedb ever launch frontend querying with JWTs like Supabase, Hasura, Fauna?
We're still working out the kinks, but some form of this will definitely be possible.
You can already hack this by defining access policies and writing an EdgeQL proxy server that authenticates incoming requests, sets the appropriate global, and forwards the query to the database. There's a Python/Flask implementation of this pattern here[0].
We also have a JavaScript example app demonstrating access policies to simplify authorization logic using Next.js/getServerSideProps[1] and a user management platform you may have heard of called Clerk[2] :)
[0] https://github.com/edgedb/edgedb-examples/tree/main/flask-pr...
[1] https://github.com/edgedb/edgedb-examples/blob/main/nextjs-a...
[2] https://clerk.dev/
You can already hack this by defining access policies and writing an EdgeQL proxy server that authenticates incoming requests, sets the appropriate global, and forwards the query to the database. There's a Python/Flask implementation of this pattern here[0].
We also have a JavaScript example app demonstrating access policies to simplify authorization logic using Next.js/getServerSideProps[1] and a user management platform you may have heard of called Clerk[2] :)
[0] https://github.com/edgedb/edgedb-examples/tree/main/flask-pr...
[1] https://github.com/edgedb/edgedb-examples/blob/main/nextjs-a...
[2] https://clerk.dev/
Yes, we're building that capability. With 2.0 we made our protocol stateless and can tunnel it through HTTP now, allowing access to full APIs of our clients. (Although EdgeDB also exposes a REST endpoint that you can access with any HTTP client from any language).
We'll be working on tightening and adding the necessary security mechanisms to allow exposing the DB directly to web in 3.0 and onward.
We'll be working on tightening and adding the necessary security mechanisms to allow exposing the DB directly to web in 3.0 and onward.
This would be great. I'm a big fan of Hasura and not having to write crud apis. But would prefer having more or less the same query language on all clients.
Yeah, that's the dream. But there are lots of tiny details to figure out to make it really usable in prod and not gimmicky. Hasura is a great product indeed.
EdgeQL is very nice. Will there be a Haskell client in the no-so-distant future?
General client question: Which ones do you intend to officially support? Interested in Elixir client that is now community maintained.
https://www.edgedb.com/roadmap#client-language-bindings
According to the roadmap:
According to the roadmap:
- Python, Javascript/Typescript, HTTP are done
- Go, Rust, Ruby, Java, and .NET are planned
We already have a Go driver as well[0] and you can get pretty far by executing queries over HTTP[1] though that's not as capable as a full client. As you said, the roadmap needs some freshening up.
[0] https://github.com/edgedb/edgedb-go
[1] https://www.edgedb.com/docs/clients/http/index#edgeql-over-h...
[0] https://github.com/edgedb/edgedb-go
[1] https://www.edgedb.com/docs/clients/http/index#edgeql-over-h...
I really like EdgeDB so far. Only played around with it for side projects up to this point but with 2.0 and the introduction of Object Level Security I will definiteyl use it in production.
The EdgeQL is the first graph-based query language that is more intuitive to me than plain SQL and the local dev experience has been far smoother than pretty much any other db I’ve used to date. Really excited to see this project mature.
The EdgeQL is the first graph-based query language that is more intuitive to me than plain SQL and the local dev experience has been far smoother than pretty much any other db I’ve used to date. Really excited to see this project mature.
Thank you, we'll keep pushing! :)
Thanks for sharing. Wasn't aware of EdgeDB and running through the interactive tutorial now. As a general novice when it comes to databases (only ever interacted with pretty mature database systems on the job, never implemented one myself) I've always struggled with a personal lack of intuition when it came to getting comfortable with SQL. So far that's not the case with EdgeDB from what I've seen. I'm excited to dig into this a more and try it out with a personal project I'm working on.
Thank you! Yeah, we spent significant amount of effort making the syntax of EdgeQL logical and predictable. Most of the time, queries can be read from top to bottom easily, even when you don't know EdgeQL.
Looks good :)
Only downside (ok more philosophy choice ?) is that it seems quite strict on schema ?
Ive been exploring none-strict schema dbs xtdb or solr. And for unexplored problems (are they not all like that ?) schemaless has been an interesting tool in my toolbox (ymmv)
Scemaless does sound like an 'absolute' and the opposite is probably 'struct-to-table-mapping' which is okish in a dynamic language and downright horrible in my second favourite language Go
I like the query 'language' of EdgeDB but then if you looking for sql alternative (language + methodology wise) look into datalog-like dbs and their query language. Datahike, datalevine, xtdb and of course datatomic. Datalogic-query-lang really offers a nice alternative in my view.
All of the above is not a silver bullet but a worthwhile alternative to at least investigate for your needs :)
Once again Well.done to EdgeDB as a solo or just a dev in general i know how hard it is to release or just get something out there, nevermind opensource
Only downside (ok more philosophy choice ?) is that it seems quite strict on schema ?
Ive been exploring none-strict schema dbs xtdb or solr. And for unexplored problems (are they not all like that ?) schemaless has been an interesting tool in my toolbox (ymmv)
Scemaless does sound like an 'absolute' and the opposite is probably 'struct-to-table-mapping' which is okish in a dynamic language and downright horrible in my second favourite language Go
I like the query 'language' of EdgeDB but then if you looking for sql alternative (language + methodology wise) look into datalog-like dbs and their query language. Datahike, datalevine, xtdb and of course datatomic. Datalogic-query-lang really offers a nice alternative in my view.
All of the above is not a silver bullet but a worthwhile alternative to at least investigate for your needs :)
Once again Well.done to EdgeDB as a solo or just a dev in general i know how hard it is to release or just get something out there, nevermind opensource
Thanks!
> is that it seems quite strict on schema ?
Yes, it is. But you can use JSON in your schema, we have amazing support for it on all levels (the query language, std library, schema integration, client APIs, etc).
> is that it seems quite strict on schema ?
Yes, it is. But you can use JSON in your schema, we have amazing support for it on all levels (the query language, std library, schema integration, client APIs, etc).
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...
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...
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
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
Thanks for the answer! It was clear to me that you were using Postgres under the hood, but it was not clear to me that your implementation was completely stateless. As a suggestions, maybe it might be useful to have a documentation page with some general EdgeDB architectural/internal structure information? I think that could be useful for future contributors as well.
Anyway, for others looking into a completely separate deployment, running EdgeDB against a postgres cluster can apparently easily be done using the `EDGEDB_SERVER_BACKEND_DSN` variable in their docker container.
https://www.edgedb.com/docs/guides/deployment/docker#edgedb-...
Anyway, for others looking into a completely separate deployment, running EdgeDB against a postgres cluster can apparently easily be done using the `EDGEDB_SERVER_BACKEND_DSN` variable in their docker container.
https://www.edgedb.com/docs/guides/deployment/docker#edgedb-...
Been using EdgeDB for ~6 months and it's great. I do wish the documentation was better (more examples please!). I spent more time than should be necessary trying to figure out simple things like NOT NULL, or how to get a backref for a linked table.
Would really appreciate it if you could open issues in the main [1] repo and we'll figure it out. We're investing a ridiculous amount of time into our docs and want them to be the best possible.
[1] https://github.com/edgedb/edgedb
[1] https://github.com/edgedb/edgedb
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 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) we could more or less achieve the same level of productivity (Relational Classes in SQLModel) and still be close to the PostgreSQL, using SQL when we want to etc.
Again this is not to bash on EdgeDB just saying its rather tough to have to constantly shift attention to the next shiny thing when the boring way is still a solid ground for majority of use cases.
My first impressions were that this is some type of Prisma + Graph/SQL hybrid language but uncertain about introducing more obfuscation for limited productivity gains that I can find.
What I want to see are large established companies using a tech for a while, not startups.
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) we could more or less achieve the same level of productivity (Relational Classes in SQLModel) and still be close to the PostgreSQL, using SQL when we want to etc.
Again this is not to bash on EdgeDB just saying its rather tough to have to constantly shift attention to the next shiny thing when the boring way is still a solid ground for majority of use cases.
My first impressions were that this is some type of Prisma + Graph/SQL hybrid language but uncertain about introducing more obfuscation for limited productivity gains that I can find.
What I want to see are large established companies using a tech for a while, not startups.
> 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 whatever you like best.
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 whatever you like best.
will give it a whirl
There is prior art for the "object relational" databases. Used WakandaDB (from the 4D creators) ~10+ years ago fairly heavily and in most ways it was way ahead of its time.
The UI editor was fantastic: https://raw.githubusercontent.com/datamosaic/data-sutra-waka...
The query language was imperative in the "fluent" style:
var record = ds.Group.query("name = :1",group).first();
Really psyched about what EdgeDB is doing moving this space forward. The declarative composable query language is a paradigm shift imo — not just a better ORM.
The UI editor was fantastic: https://raw.githubusercontent.com/datamosaic/data-sutra-waka...
The query language was imperative in the "fluent" style:
var record = ds.Group.query("name = :1",group).first();
Really psyched about what EdgeDB is doing moving this space forward. The declarative composable query language is a paradigm shift imo — not just a better ORM.
> The declarative composable query language is a paradigm shift imo — not just a better ORM.
This!
This!
Why's NOT NULL a problem? ("required property" syntax is already in quickstart examples)
I think the OP meant `NOT NULL` as in nullness check in queries. EdgeQL uses `exists <foo>` to check for existence of data. We have examples in the cheatsheet and elsewhere but it's probably hard to find if you're looking for "NOT NULL" specifically. We'll see about a way to improve the discoverability of this.
I see, that makes sense, thanks.
Congrats on 2.0 release, this is the first I'm hearing of EdgeDB. As someone who is not a DBA and dreads working w/ complicated SQL queries, this looks like a breath of fresh air.
Hope it continues to grow in features and support!
Hope it continues to grow in features and support!
Thanks! I think most people dread working with complicated SQL queries, especially experienced DBAs :)
Currently watching the launch event! :)
I took a look at the low level stuff, compiled it and tried breaking it and pushing it to the limits. It's quite stable, something that you would expect from a Python Core developer as a founder.
My only concern is that the actual `edgedb-server` CLI isn't documented at all.
I took a look at the low level stuff, compiled it and tried breaking it and pushing it to the limits. It's quite stable, something that you would expect from a Python Core developer as a founder.
My only concern is that the actual `edgedb-server` CLI isn't documented at all.
Haha, thanks so much!
`edgedb-server --help` is pretty elaborate, but yeah, we don't have an official page. What kind of info are you looking for?
`edgedb-server --help` is pretty elaborate, but yeah, we don't have an official page. What kind of info are you looking for?
[deleted]
very nice.
you may want to check out openziti (open source) to eliminate vpn (while closing EdgeDB server and Postgres server link listeners and open IB FW ports). can be done agentless via sdk, or modified jdbc driver. basic postgres example video here: https://youtu.be/s-skpw7bUfI
disclosure: i run a company that built saas on top of the openziti open source.
you may want to check out openziti (open source) to eliminate vpn (while closing EdgeDB server and Postgres server link listeners and open IB FW ports). can be done agentless via sdk, or modified jdbc driver. basic postgres example video here: https://youtu.be/s-skpw7bUfI
disclosure: i run a company that built saas on top of the openziti open source.
Thanks!
Can you improve the deployment story for wireguard to match the native PostgreSQL experience? Currently deploying EdgeDB requires setting up multiple VPN connections and environmental variables. Ideally it should be one click, zero-config just like Postgres.
Congrats. EdgeDB is really a game changer.
One thing I'm excited about is a framework that uses EdgeDB instead of ORM+SQL. This would make the framework itself leaner and lead to writing less code since the db can do so much more!
One thing I'm excited about is a framework that uses EdgeDB instead of ORM+SQL. This would make the framework itself leaner and lead to writing less code since the db can do so much more!
Thanks! Depends on what kind of frameworks you like. EdgeDB+Next.js or EdgeDB+Flask are very pleasant to use already. But there's no heavyweight one like Django or RoR just yet.
Would you foresee any difficulties using EdgeDB with Django?
I know there would be no need to use Django's ORM and migrations if using EdgeDB - but then again I might use EdgeDB and SQLite (for FTS in the near term and mobile/offline in the long term), so maybe Django migrations still helpful there
I know there would be no need to use Django's ORM and migrations if using EdgeDB - but then again I might use EdgeDB and SQLite (for FTS in the near term and mobile/offline in the long term), so maybe Django migrations still helpful there
I think you'll be able to use Django alright, but half of its value prop is their ORM and admin panel. Both of which you don't need with EdgeDB.
Hey EdgeDB, SQLAlchemy guy here!
EdgeDB is of course beautiful but any thoughts on how the Python client might support pep-484 integration? if all the queries are strings, the Python code has no way to know anything about what datatypes the returned records would have, unless you spell it out explicitly for every query which is very cumbersome. You'd need something that looks more like SQLAlchemy's class definitions corresponding to EdgeDB types for that to be possible (that is, something that looks more like a Python DSL/ORM type of thing).
EdgeDB is of course beautiful but any thoughts on how the Python client might support pep-484 integration? if all the queries are strings, the Python code has no way to know anything about what datatypes the returned records would have, unless you spell it out explicitly for every query which is very cumbersome. You'd need something that looks more like SQLAlchemy's class definitions corresponding to EdgeDB types for that to be possible (that is, something that looks more like a Python DSL/ORM type of thing).
Could you use efficiently query a page for all its comments? Like an HN page or Reddit page?
Currently I’m using materialized paths to handle this but it would be awesome if I no longer have to as it’s a bit of a hairball
Currently I’m using materialized paths to handle this but it would be awesome if I no longer have to as it’s a bit of a hairball
Efficient transitive closure (aka link recursion) is something we plan to tackle soon (see https://github.com/edgedb/edgedb/discussions/2634 for some discussion on the topic).
Does EdgeDB support full text search queries?
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
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.
That’s great to hear. Option 3 is the best choice too as it allows for the FTS results to also be constrained by the object level security access logic. Thanks for the great work and replies!
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.
Yes, we'll be adding a way to choose the index type. It's even more relevant now that we've exposed range types.
Will be a feature of 3.0 in 6 months. We want to do it right and allow transparent integration with things like elastic, as well as allowing faceted search.
I believe these are the people behind the asyncpg Postgres library for Python. We use it daily, thanks :)
Yeah. Also behind uvloop :blush:
Questions:
SQL schemas are rigid and hard to refactor, does EdgeDB solve this?
I would like to know more about why building a graph db on top of postgres will be better than building a native graph database directly? (With numbers, not "pg is fast")
SQL schemas are rigid and hard to refactor, does EdgeDB solve this?
I would like to know more about why building a graph db on top of postgres will be better than building a native graph database directly? (With numbers, not "pg is fast")
EdgeDB seems more popular in NA and Europe. See https://ossinsight.io/analyze/edgedb/edgedb
Wow, that's one great dashboard. Thanks for sharing.
> extends the relational model to eliminate the objet-relational impedance mismatch
Anyone remembering object databases and the ODMG standard? It had even a query language called OQL which was an OO superset of SQL.
Anyone remembering object databases and the ODMG standard? It had even a query language called OQL which was an OO superset of SQL.
Just a side note: EdgeDB doesn't implement OOP persistence, so it's not an classical object database.
Sure, but I recognize concepts we were dealing with in the nineties; I assume you are aware of ODMG and OQL.
Yes, you can easily put OQL in the list of prior art EdgeQL was inspired by.
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.
Is EdgeDB suitable for OLAP or is it focused on OLTP queries?
With the addition of `GROUP` in 2.0, EdgeDB is as suitable for OLAP as vanilla Postgres is (unless you absolutely need window functions, which we don't implement yet).
Thank you. The more OLAP support the better (at least for us).
Congrats to the team, looking forward to testing out the new changes! I'd love to see some examples on non-trivial schemas realized in EdgeQL for reference.
I'm going to start writing some case studies soon about how various companies use EdgeDB in prod. I'm sure we'll spot some interesting schemas and patterns to share :)
I actually dig the declarative schema syntax. Is it something separate that one can use in various programming languages, or is it specific to EdgeDB?
It's specific to EdgeDB. And part of what makes it great is a tight integration with our query language - EdgeQL. You can specify aliases, default expressions, access policies with arbitrary EdgeQL expressions in your schema.
Fun fact: our schema declaration language is actually a trimmed down DDL syntax of our query language.
Fun fact: our schema declaration language is actually a trimmed down DDL syntax of our query language.
Thanks for responding.
I am asking because more and more I see a need for universal type-describing language, one that transcends the programming languages and can be used for various things e.g. specifying DB schemas, code-level invariants, generating network clients to interact with a service, and many others.
It's a passion and I am going around gathering data on such syntaxes and trying to ascertain their viability. Your answer helped.
I am asking because more and more I see a need for universal type-describing language, one that transcends the programming languages and can be used for various things e.g. specifying DB schemas, code-level invariants, generating network clients to interact with a service, and many others.
It's a passion and I am going around gathering data on such syntaxes and trying to ascertain their viability. Your answer helped.
[deleted]
Could you please elaborate, What is the state of using postgresql extensions and PL UDF in EdgeDB?
Is it on the roadmap?
I couldn’t get past the lack of `SELECT *` support last time I played with this, but looking forward to trying it again!
We'll have that in 3.0; we're shooting for a more advanced splat-like syntax. Simple * wouldn't cut it because one of the principals of EdgeQL is to fetch only what you need, aiming for efficiency. That said, our UI repl has autocomplete and a `*` option in it, that expands it to all fields. We might implement something similar in the command-line REPL too.
Will there ever be a full golang library with a query builder or codegen? Something along the lines of entgo perhaps?
The Go client implements the full client API, but yeah, it lacks the query building capability. We want all of our client APIs to have it; it's a matter of time, but I don't have a concrete ETA on when we get to it. Hopefully in the coming months. Here's a blog post by one of our users and it has some feedback on edgedb-go: https://divan.dev/posts/edgedb/
Yes: https://github.com/edgedb/edgedb-go/issues/182
Feel free to jump in with suggestions, we need feedback from experienced Go devs.
Feel free to jump in with suggestions, we need feedback from experienced Go devs.
When do you think it will be possible to migrate an existing Postgres database to EdgeDB?
Automatically - we might have some built-in scripts in time for 3.0. You can migrate manually now by writing some sql/edgeql scripts.
And I bet the team would help with those migration scripts if you asked!
Obviously :)
Interesting; looks a bit like a modernized CODASYL on top of a Codd model.
It sounds great, but being in Python still gives me a bit of concern.
Only the query compiler is in pure Python and you only hit that once per query, as the compilation result is trivially cached. The hot path is a combination of Cython, C and Rust. We have a suite of benchmarks [1] that show relative overhead of EdgeDB compared to raw Postgres is quite low.
[1] https://github.com/edgedb/imdbench
[1] https://github.com/edgedb/imdbench
It's not a rational concern, but it still is a concern.
Is there any plans for A Dart Client for flutter
Will edgeql_https be supported at some time?
I like being "close to the metal" when it comes to database queries. I don't want to learn an ORM api, and neither EdgeQL; I just want to do the thing I already know how to do.
PureORM[0] is this right balance of write SQL, get properly structured data.
[0] https://github.com/craigmichaelmartin/pure-orm
PureORM[0] is this right balance of write SQL, get properly structured data.
[0] https://github.com/craigmichaelmartin/pure-orm
EdgeDB is a long-term effort for a DB/query language that's as intuitive as possible for the greatest number of people. The early adopters are primarily those who are frustrated by ORMs and/or SQL, as you'd expect. But you should pick whatever makes you most productive—if you're already productive and happy with SQL, then that's definitely the right choice! Good luck with PureORM, looks very cool.