EdgeDB employee here. This is our final beta release, which will be followed swiftly by a release candidate in a couple weeks, then a stable 1.0 shortly thereafter. (Finally!)<p>A brief overview of what we're trying to do: we think some of the design choices in SQL are holding back relational DBs from providing the best possible developer experience. Namely: non-composable syntax[0], the lack of a standardized mechanism for declarative schema modeling, and the lack of a first-party migrations system. The lack of these things is deeply felt, as evidenced by the popularity of ORMs (despite their tradeoffs).<p>We're aiming for a unified DX, with first-party tooling/syntax for declaratively defining your schema[1], generating and applying migrations[2], and writing queries with EdgeQL. EdgeQL is a spiritual successor to SQL that’s composable, compact, and eliminates the need for foreign keys/JOINs (as it’s deeply integrated with our graph-like schema modeling system). A quick overview of the syntax is here[3].<p>We’ve received a lot of great feedback on HN over the years. Feel free to check out some recent threads about the design of EdgeQL[4] and the limitations of SQL[5].<p>[0] <a href="https://www.edgedb.com/blog/we-can-do-better-than-sql" rel="nofollow">https://www.edgedb.com/blog/we-can-do-better-than-sql</a><p>[1] <a href="https://www.edgedb.com/showcase/data-modeling" rel="nofollow">https://www.edgedb.com/showcase/data-modeling</a><p>[2] <a href="https://www.edgedb.com/showcase/migrations" rel="nofollow">https://www.edgedb.com/showcase/migrations</a><p>[3] <a href="https://www.edgedb.com/showcase/edgeql" rel="nofollow">https://www.edgedb.com/showcase/edgeql</a><p>[4] <a href="https://news.ycombinator.com/item?id=27793398" rel="nofollow">https://news.ycombinator.com/item?id=27793398</a><p>[5] <a href="https://news.ycombinator.com/item?id=24106608" rel="nofollow">https://news.ycombinator.com/item?id=24106608</a>