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.
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.
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.
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.
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?
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)
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?
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.
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.
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.
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.
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)
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)?
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.
> 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?
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.
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.
> 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.
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.
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.
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] :)
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.
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.
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.
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.
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.
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
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).
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?
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.
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.
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.
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)
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.
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 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.
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.
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!
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.
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.
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.
Yeah, that will all be simplified when we launch our cloud. Our goal is to make it possible to deploy to cloud with one short cli command. We'll have it soon.
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
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).
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.
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.
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")
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.
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).
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 :)
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.
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.
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.
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/
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.
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.
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.
