23 ms·

Show HN: EdgeDB 1.0

• 1st1 5y ago
  EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4 https://www.youtube.com/watch?v=WRZ3o-NsU_4
  • j-pb 5y ago
    Hey Yury, Cool stuff! How do you folks solve the large amount of joins that are the result of graph queries? Any worst-case-optimal multi-way-join secret sauce :D? Also, with DBs like Datomic competing in the same area, do you have an immutability/versioning story?
    • 1st1 5y ago
      Thanks! The secret sauce is to pack nested shape queries into array_agg-ed SQL subquery. So we never select unnecessarily wide rows.
      • kall 5y ago
        Sounds like this is not dissimilar from the GraphQL-to-SQL compiler in Hasura, which also brings out surprising performance for wildly nested frontend queries.
        • 1st1 5y ago
          Yeah, indeed, Hasura uses json_agg, which is similar but returns you a JSON string. We use array_agg, so we often avoid data serialization altogether. Our binary protocol just lets the data messages pass through with the original binary encoding. And because we fully control the schema, we can make all sorts of interesting optimizations, like implementing high-perf data codecs on the client side to unpack data fast.
          • kall 5y ago
            Yeah, that‘s an appealing idea, if there never even has to be any json. Hasura has the frontend safe API and strong authz going for it. Is that something you might also do, or are you focused on serving the backend? End-user row and column level authz gives me a lot of peace of mind when writing bigger queries.
  • boxed 5y ago
    Is there an eta or public wip of a python query builder?
    • 1st1 5y ago
      Our topmost priority now is launching a hosted version of the product, all hands on deck. Having a proper (and potentially fully type-safe) query builder for Python is literally the next to-do.
  • Dnguyen 5y ago
    How do we migrate from existing Postgres database to EdgeDB? Can traditional app still access all the relational as before and new app access via EdgeDB? We're making use of existing environment and extending it with our own frontend. I would like to understand how I can mix legacy and new code.
    • 1st1 5y ago
      We plan to introduce a tool for assisting migration from SQL databases, but at this very moment, the only way to migrate an existing app is to re-create your DB schema in EdgeDB and then write a script to import the data. EdgeDB right now is definitely more geared towards starting new projects with it.
    • infogulch 5y ago
      Maybe if you move all data to be managed by EdgeDB, then create a separate "legacy" schema that just contains views & triggers that forwards queries and mutations to the EdgeDB database.
  • mritchie712 5y ago
    Do you support columnar storage? i.e. to make analytics queries fast.
    • 1st1 5y ago
      Not yet, but theoretically we might support something like Timescale in the future.
  • hyuuu 5y ago
    do you have plans to integrate with prisma? it's almost a DIRECT translation of how the query is expressed in Prisma compared to edgedb. Googling quickly, it seems there is a ticket already. I wonder if this could be a low hanging fruit and a great growth channel since prisma is very popular. https://github.com/prisma/prisma/issues/10210 https://github.com/prisma/prisma/issues/10210
    • 1st1 5y ago
      Not really, there's no point in using prisma with EdgeDB as our own query builder is more idiomatic for our product, faster, and we gape more capable. See also this reply by Colin: https://news.ycombinator.com/item?id=30293544 https://news.ycombinator.com/item?id=30293544
  • torartc 5y ago
    Any plans to have a gui?
    • 1st1 5y ago
      Yes, it's in the works!
  • torartc 5y ago
    Dumb question, how do you exit the shell? I feel like I've scoured the docs and can't find it.
    • colinmcd 5y ago
      \q or \quit If you get stuck, run \help for a list of commands.
    • msully4321 5y ago
      What colin said, or (in every terminal emulator I've used), ctrl-d to send end of file, which will close it.
      • sizediterable 5y ago
        Congrats Sully and thanks for your work on mypy!
      • torartc 5y ago
        That's interesting, I've always though ctrl-c would close things. I tried so many things like "quit" "exit" ctrl-c "help"
        • emj 5y ago
          Ctrl-c cancels running processes, but not shells. When a process becomes a shell I can not say, but if make an infinite loop in the Python repl you can Ctrl-C that loop. $ python >>> while True: ... pass ... ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> KeyboardInterrupt
  • nextaccountic 5y ago
    I have a few questions I can't find after skimming the documentation.. Can someone use Postgres extensions with EdgeDB, like TimescaleDB, PostGIS, Zombodb and Postgres_fdw? How are sum types (called enums in Rust) modelled in EdgeDB? (like Rust's Result). Do I need to define it with inheritance, where each variant inherits from it? What about adding specific syntax for sum types? edit: also, I see there's a WIP custom #[derive] for Rust in https://github.com/edgedb/edgedb-rust https://github.com/edgedb/edgedb-rust - can it store Rust types on EdgeDB? Something like http://diesel.rs/ http://diesel.rs/ or even https://lib.rs/crates/turbosql https://lib.rs/crates/turbosql
    • 1st1 5y ago
      Regarding extensions: we plan to wrap the most popular ones like PostGIS to give them idiomatic EdgeQL flavor. We need to do a bit of work to make that the right way. Sum types can be modeled with inheritance. You can create an abstract base type and use that as target for the links. You can then derive types from it and write polymorphic EdgeQL queries to select/match data. Rust client is still work on progress, not really open to tinkering unless you want to experiment.
  • ranguna 5y ago
    I looked through the documentation and all I could find was how to spin this up locally. How do I run this on the cloud? Do you offer fully managed service to host this or do I need to spin up some compute instances of my own ?
    • ranguna 5y ago
      Found it: https://www.edgedb.com/docs/guides/deployment/index https://www.edgedb.com/docs/guides/deployment/index Can't wait for edgeDB cloud!
  • the-alchemist 5y ago
    What advantages/disadvantages does EdgeDB have over Dgraph.io?
    • colinmcd 5y ago
      Unfortunately DGraph is having some serious troubles as a company: https://discuss.dgraph.io/t/quitting-dgraph-labs/16702 https://discuss.dgraph.io/t/quitting-dgraph-labs/16702 Technically speaking though, using GraphQL as a data model is quite limiting: just basic scalar types and a handful of custom types implemented by DGraph (Polygon, etc). By contrast EdgeDB schemas support a much wider range of granular types, constraints, computed properties, link properties, etc. Perhaps more importantly EdgeQL is a full query language with composable syntax, a standard library of functions and operators, for loops, primitive literal manipulations (e.g. string indexing and slicing), the ability to cast values to different types, subqueries, etc. Basically it's a complete query language contrast GraphQL is closer to an ORM in that it really only supports CRUD. I think DQL is marginally more powerful though admittedly I'm not very familiar with it: https://dgraph.io/docs/get-started/ https://dgraph.io/docs/get-started/
• jonking 5y ago
  Why a new language? I can see and understand why and where graphs beat out SQL, but what does EdgeQL have over existing graph languages? Eg. vs Cypher or the likely-Cypher-compatible forthcoming GQL standard? https://www.gqlstandards.org/ https://www.gqlstandards.org/
  • hobofan 5y ago
    Forthcoming? Given that the last sign of live has been from 3 years ago in a space with already little movement GQL seems to be most likely dead.
    • hvacker 5y ago
      Well, the last update on the official ISO page https://www.iso.org/standard/76120.html https://www.iso.org/standard/76120.html is from November 2021. Does not look that dead to me. Standardization projects typically take awhile, specifically for something complicated as a query language spec.
      • keithwhare 5y ago
        The international committee (ISO/IEC JTC1 SC32 WG3 Database Languages) that is responsible for the database language standards SQL and GQL is pretty good at writing standards and not as good at taking about the work in progress. SC32 WG3 is developing two related standards to support property graphs: 1. SQL/PGQ (ISO/IEC JTC1 9075 part 16) -- This adds language to create property graph views on top of existing SQL tables and write property graph queries in a GRAPH_TABLE function in an SQL FROM statement. 2. GQL (ISO/IEC JTC1 39075 Database Language GQL) -- This is a full declarative property graph database language to create, maintain, and query graphs. This includes support for both descriptive and prescriptive schemas. The Graph Pattern Matching language is identical between the two standards. For more details about GPM, see https://arxiv.org/abs/2112.06217 https://arxiv.org/abs/2112.06217 The ISO process has a defines series of milestones. I will spare you the details at the moment. SQL/PGQ will start a Draft International Standard (DIS) ballot in July 2022 and so will be a published standard next year - 2023. GQL will finish a Committee Draft (CD) ballot this month (February 2022) and should be ready for a DIS ballot in early 2023. However because GPM is shared between SQL/PGQ and GQL, the GQL Graph Pattern Matching will be stable when SQL/PGQ goes to DIS ballot. For a little more detail on the GQL standards process and content, take a look at the talks from the LDBC TUC meeting August 2021: https://ldbcouncil.org/event/fourteenth-tuc-meeting/ https://ldbcouncil.org/event/fourteenth-tuc-meeting/
• tailhook 5y ago
  Hurray!
• colinmcd 5y ago
  EdgeDB employee here. We're beyond excited to finally publish a stable release of EdgeDB after 4 years of active development and 15 pre-releases. Happy to answer any questions on here!
  • rmbyrro 5y ago
    4 years!? Wow, I can't imagine how you guys are feeling today, congrats and all the best to the project!
    • 1st1 5y ago
      For the full story read another blog post: https://www.edgedb.com/blog/building-a-production-database-in-ten-years-or-less https://www.edgedb.com/blog/building-a-production-database-i... :)
• YohAsakura 5y ago
  The live presentation is happening right now: https://www.youtube.com/watch?v=WRZ3o-NsU_4 https://www.youtube.com/watch?v=WRZ3o-NsU_4 Very interested in what data engineers think about this project! I am not a developer, but the founders (including Yury Selivanov, Python Core Developer, see also https://github.com/MagicStack https://github.com/MagicStack) and the fact that these people have been investing in the project for four years already, make me think that EdgeDB can be an important project for the database world!
• smw 5y ago
  Can you front cockroachdb as it exposes a (mostly) postgresql api?
  • your_challenger 5y ago
    > 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. Even then we've bumped into the ceiling quite a few times, and needed to send patches and bug reports upstream. That's also why EdgeDB currently requires PostgreSQL 13 or later. https://github.com/edgedb/edgedb/discussions/3403 https://github.com/edgedb/edgedb/discussions/3403
• sakopov 5y ago
  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?
  • 1st1 5y ago
    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!
    • Serow225 5y ago
      it seems like it would be a great fit for creating a LINQ IQueryProvider :D Which would be amazing
• kurjam 5y ago
  At the time of writing, docs have a large typo in them: https://www.edgedb.com/docs/clients/01_js/driver https://www.edgedb.com/docs/clients/01_js/driver impoart * as edgedb from "edgedb";
  • 1st1 5y ago
    Thank you!
• josefrichter 5y ago
  Is this a potential alternative to graph databases too? How does it compare to them?
  • 1st1 5y ago
    If you use a graph database to store application data and you want a strict schema (and potentially improved performance), then YES. If you use a graph database to run graph algorithms on your data, then NO. Although we'll be working on adding support for recursive queries to EdgeQL in the near future.
    • gazpacho 5y ago
      Right on. I have been in the position before where I needed to do some graph-like queries (where I had to traverse several levels of joins with the number of joins unknown a priori) but at the same time this was an application storing structured data. I found myself in a tight spot between doing some really clunky Postgres stuff or going the graph DB route. I would have loved to have something that can be used like a relational DB 95% of the time but can still handle that 5% of graph-like queries with reasonable performance and complexity.
      • josefrichter 5y ago
        maybe have a look at arangodb, I think their value proposition is something like you wrote.
        • gazpacho 5y ago
          indeed I remember looking at them. this was years ago, and I'm no longer on the project though :)
        • gazpacho 5y ago
          this is still one of my favorite articles though: https://www.arangodb.com/learn/graphs/time-traveling-graph-databases/ https://www.arangodb.com/learn/graphs/time-traveling-graph-d...
• rahimiali 5y ago
  Could someone explain what a graph-relational database is? I'm not able to extract a technical definition from the paragraph below: "What is a graph-relational database? EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relational model. This makes EdgeDB an ideal database for application development."
  • RedCrowbar 5y ago
    (EdgeDB CTO here) In a classic relational model everything is a tuple containing scalar values. Graph-relational extends the relational data model in three ways: - every relation always has a global immutable key independent of data (explicit autoincrement keys aren't needed) - this enables us to add a "reference type", which is essentially a pointer to some other record (i.e. a foreign key) - attributes can be set-valued, so you can have nested collections in queries and in your data model. This is what lets us do `Movie.actors.name` instead of a bunch of `JOINs`, because `actors` is declared as a set-valued reference type in the `Movie` relation.
    • miohtama 5y ago
      This is a nice example. How the data is stored physically? Does the model work for large datasets and when it could break down? What are optimal workloads? Do we still need to fiddle with indexing and such?
      • RedCrowbar 5y ago
        Data is stored relationally in Postgres in 3NF. References are indexed automatically, but you still need to index type properties if you use them in `filter`.
        • samhw 5y ago
          Wait, it stores the data in Postgres? So this is essentially a data model on Postgres? FWIW, I do think there's a space in the market for a thin wrapper over Postgres (or MySQL) which would automate certain optimisations such as whether to index a particular table. It always struck me as perverse that that optimisation was delegated to the developer, when it's no more subjective or application-specific than a thousand other automated optimisations the engine makes. I'd be really interested if your project covered that.
• KwisaksHaderach 5y ago
  EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relational model. I don't see how can they retain the performance of the relational model when using graphs on top of PG unless they are using PG as storage k/v layer only.
  • robertlagrant 5y ago
    Why's that?
  • 1st1 5y ago
    The key insight here is that we still have schema. We have high-level object types and a first-class notion of a "reference" - we call it "link". Our other extension of the relational model is that every "row" must have a unique ID. Both things combined implement a graph or your types and a graph of your data as it's stored in the underlying tables. Everything is strictly typed and efficient. But EdgeDB isn't ideal for storing loosely typed graph data, neo4j is built for that.
  • 1st1 5y ago
    See also: https://news.ycombinator.com/item?id=30291538 https://news.ycombinator.com/item?id=30291538
  • Rapzid 5y ago
    https://www.alibabacloud.com/blog/postgresql-graph-search-practices---10-billion-scale-graph-with-millisecond-response_595039 https://www.alibabacloud.com/blog/postgresql-graph-search-pr... Can use these techniques on top of typical, existing relation model tables as well. Consider a join table, or even a polymorphic join table, that gives you the edges. But you can use unions and stuff to join up data across various tables. Can get really creative with it.
• sverhagen 5y ago
  > the first open source, graph-relational database OrientDB?
  • 1st1 5y ago
    As far as I'm aware OrientDB don't call themselves "graph-relational". In fact, they're positioning themselves as a multi-model NoSQL database. Where's EdgeDB positions itself as a relational database and a successor of SQL.
    • waterbase 5y ago
      Dgraph.io? How you guys compare yourself to dgraph database?
      • 1st1 5y ago
        IIRC Dgraph is schemaless. EdgeDB is schema-first, which gives you type-safety and that amazing TypeScript query builder autocomplete experience :)
        • hotfixguru 5y ago
          Does this autocomplete experience translate into IDEs when using client libraries, such as the Python library?
• say_it_as_it_is 5y ago
  I think this work is absolutely commendable, but at the end of the day it's a database written in Python with Rust extensions sprinkled here and there. Is 1.0 your MVP?
  • 1st1 5y ago
    EdgeDB is built on top of Postgres. The performance critical bits are either Python compiled to C with Cython or Rust, so there's almost no Python overhead. We perform quite favorably in benchmarks, see our old blog post with some: https://www.edgedb.com/blog/edgedb-1-0-alpha-2#results https://www.edgedb.com/blog/edgedb-1-0-alpha-2#results > Is 1.0 your MVP? EdgeDB is ready for production and is light years ahead of its first technical preview MVP release published a few years ago.
    • pier25 5y ago
      Would be interesting to know how it fares against Prisma which is becoming pretty popular these days.
      • gazpacho 5y ago
        and to get updated benchmarks in general
        • 1st1 5y ago
          Working on that!
• xdfg13345 5y ago
  Typo in the post "and also retrive the list of top 5" should be retrieve
  • 1st1 5y ago
    Good catch! A fix will be deployed in a couple of minutes :)
• yewenjie 5y ago
  I tried the beta around August last year. I struggled grokking it mostly because I had had very minimal experience with SQL - which it kind of assumed you already know the drawbacks of. However, I did like the idea very much. Looking forward to giving it another try soon!
  • 1st1 5y ago
    Thank you! Working EdgeDB requires 0 SQL knowledge, you are not going to ever use it again. To quickly learn EdgeQL I recommend our online interactive in-browser tutorial: [1] We also have a book, it's called Easy EdgeDB, check it out here: [2] [1] https://www.edgedb.com/tutorial https://www.edgedb.com/tutorial [2] https://www.edgedb.com/easy-edgedb https://www.edgedb.com/easy-edgedb
    • nicoburns 5y ago
      I suspect it was not specifically SQL knowledge they were lacking, but knowledge of how to work with relational databases.
• tluyben2 5y ago
  Congrats! Can I get the ebook as pdf somewhere?
  • 1st1 5y ago
    An ebook with Easy EdgeDB (https://www.edgedb.com/easy-edgedb https://www.edgedb.com/easy-edgedb)?
    • tluyben2 5y ago
      Yes, maybe I am blind (I am on mobile at the moment), but I would like the PDF of the book if you have it.
      • henryfjordan 5y ago
        It's available as a set of Markdown files in a git repo, if that helps: https://github.com/edgedb/easy-edgedb https://github.com/edgedb/easy-edgedb
• nikhilsimha 5y ago
  Won't the functional variant read better than the SQL dialect movie_reviews .filter(_.actor.name.lowercase() == "Zendaya") .groupBy(_.title, _.credit_order, avg(_.ratings)) .sortBy(_.credit_order) .take(5) vs. select Movie { title, rating := math::mean(.ratings.score) actors: { name } order by @credits_order limit 5, } filter "Zendaya" in .actors.name
  • RedCrowbar 5y ago
    It's a matter of taste. We decided to do a "looks like SQL + GraphQL" style because that's what most people are familiar when they think about a query language. That said, the functional variant is a likely way to represent EdgeQL in programming languages.
  • 1st1 5y ago
    Keep in mind that EdgeQL is a query language that can be used from any programming language (either over the official libraries, or over HTTP). Functional JS-inspired dialects aren't appealing to everybody.
  • udfalkso 5y ago
    I like the flow of yours, but it doesn't capture the GraphQL piece. Where do you specify the nested limit and desired fields for the inner "actors"?
  • cakoose 5y ago
    Your query returns 5 rows total. The EdgeDB query returns all movies that Zendaya is in [1] and, along with each movie, the first 5 credited actors. Also, it looks like your version also does implicit joins (like EdgeDB), but I'm not sure how they would work in that style. [1] Or maybe only movies where Zendaya is in the first 5 credited actors; I'm not sure.
• gfodor 5y ago
  Congrats - this looks really interesting, and this is coming from a person who generally ignores new shiny database news. Def will be checking this out!
  • 1st1 5y ago
    Thank you! Please do and feel free to connect with us to discuss your experience :)
    • gfodor 5y ago
      if easy to answer: can this be used with eg AWS RDS? or is there something that couples the postgres engine tightly enough that's not doable?
      • 1st1 5y ago
        Yes, it can be used with rds or aurora, we have guides in the docs.
• likecarter 5y ago
  I don't understand the benefit. It's just a query language on top of Postgres? It doesn't seem to have the performance characteristics of a graph database, while acting like it does. JOINS will still be expensive. You guys shouldn't use the word graph, misleading.
  • dudus 5y ago
    I think the idea is to prove the query language more than deliver a database that has graph DB advantages. If they prove the language maybe they can implement a different backend. I'm just guessing here.
    • 1st1 5y ago
      > If they prove the language maybe they can implement a different backend. This is very true and might happen in a far future.
  • dragosbulugean 5y ago
    my thoughts exactly... a graph database is not useful because of its query language, it's useful because of its performance characteristics when bringing linked data — it could never be performant on a Postgres backend.
    • zzzeek 5y ago
      to be fair, I don't know EdgeDB's architecture but to the degree that a system can bring its graph structures into memory, using PostgreSQL as the durable storage but not for every on-demand query, it can certainly provide fast results. I would assume EdgeDB likely has concepts like this integrated into its design.
• jimmar 5y ago
  On https://www.edgedb.com/tutorial/basic-queries/objects https://www.edgedb.com/tutorial/basic-queries/objects, if I change "SELECT User.name;" to "SELECT User.Name;" the page crashes with, "Application error: a client-side exception has occurred." It crashes on Chrome and Edge.
  • 1st1 5y ago
    We'll take a look, should be a quick fix.
    • 1st1 5y ago
      Aaaaand... it's fixed!
      • svnpenn 5y ago
        Nope
        • your_challenger 5y ago
          I get a response. > InvalidReferenceError: object type 'default::User' has no link or property 'Name' > Hint: did you mean 'name'? Which is the expected response (same as the edgedb cli)
• pier25 5y ago
  This looks really cool! Are you going to support some kind of subscriptions for realtime?
  • 1st1 5y ago
    Potentially, but not in time for 2.0 (which should happen in just a few months).
• spullara 5y ago
  The query language reminds me a lot of JPA, which makes sense because this is essentially an ORM layer on top of Postgres.
  • 1st1 5y ago
    Oh, EdgeDB is so much more than "basically an ORM layer". I suggest to scroll to the bottom of our home page edgedb.com and read the dedicated FAQ entry. I just don't want to restate the entire explanation here.
    • spullara 5y ago
      The description still reminds me very much of JPA and JPQL. The implementation as proxy is nice and needed in this polyglot world.
• sagarjs 5y ago
  Looks great. Will try this out! Would a graphql API be part of your roadmap?
  • RedCrowbar 5y ago
    GraphQL is already supported: https://www.edgedb.com/docs/graphql/index https://www.edgedb.com/docs/graphql/index
• nknealk 5y ago
  Can someone from EdgeDB explain why the SQL isn't as simple as what I have below? What am I missing? Why is that cross join lateral necessary: SELECT title, ARRAY_SLICE(ARRAY_AGG(movie_actors.name WITHIN GROUP (order by movie_actors.credits_order asc)),0,5) avg(movie_reviews.score) FROM movie JOIN movie_actors on (movie.id = movie_actors.movie_id) JOIN person on (movie_Actors.person_id = person.id) JOIN movie_reviews on (movie.id = movie_reviews.id) WHERE person.name like '%Zendaya%' group by title
  • RedCrowbar 5y ago
    Because that only gives you actor names, not records, and also because arrays aren't a universal SQL feature.
    • eatonphil 5y ago
      EdgeDB is already postgres specific though.
      • RedCrowbar 5y ago
        EdgeDB currently is. Graph-relational and EdgeQL are not.
        • SahAssar 5y ago
          Until another db is graph-relational and can be queried via edgeql those are just as postgres-specific as arrays though, right?
    • nicoburns 5y ago
      You can JSON_AGG to get whole records.
      • deleted 5y ago
        [deleted]
      • 5y ago
• thatwasunusual 5y ago
  > We should not continue wasting our productivity with a database API architecture from the last century. Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.
  • starik36 5y ago
    > Show me _how_ you can beat SQL Scroll down. They do exactly that.
    • 1st1 5y ago
      Yeah, we also blogged about this extensively. Here are are some links: Pointed critique at SQL: [1] Benchmarks: [2] and [3] We'll be adding a dedicated benchmarks page to our website soon. [1] https://www.edgedb.com/blog/we-can-do-better-than-sql https://www.edgedb.com/blog/we-can-do-better-than-sql [2] https://www.edgedb.com/blog/edgedb-1-0-alpha-1 https://www.edgedb.com/blog/edgedb-1-0-alpha-1 [3] https://www.edgedb.com/blog/edgedb-1-0-alpha-2 https://www.edgedb.com/blog/edgedb-1-0-alpha-2
      • kall 5y ago
        In [3] it says "we are assessing the code complexity and performance of a simple IMDb-like website built with Loopback, TypeORM, Sequelize, Prisma, Hasura, Postgraphile, raw SQL, and EdgeDB" but then it goes on to only explain the results of the classic ORMs but not hasura, postgraphile and prisma. Are the full results available somewhere? That classic ORMs are kinda slow is probably not a surprise to anyone, the others which either get to compile the full query or have a hand in controlling the schema are more interesting. They also seem more similar to your product, running as a server and managing the schema, so most worth comparing. Edit: The fact that "Raw SQL" ends up being a suboptimal query because of the node driver limitations, which then gives you "Way faster than even raw SQL!!!" graphs also leaves a weird taste. I guess if you are comparing programming language level solutions fair enough.
• aljgz 5y ago
  One thing that can facilitate adoption is a smooth path from a working software based on Postgresql to EdgeDB: We have a software that's a GraphQL interface to a database that's populated with a project (let's call it the indexer project) we do not control. It would be great if we could check the database schema for problems it might have to be used as an EdgeDB database. Then we would migrate our application to use EdgeDB, while the indexer keeps loading our database through direct interaction with PostgreSql.
• solarmist 5y ago
  Hell yeah. This is what I've wanted ever since I first learned about Apple's CoreData. This seems great. I have a highly interrelated data model (think parsed natural language text with annotations), and writing SQL to keep all of that data aligned and synced is a pain with an ORM. Am I right in imagining this works similarly to how Apple's CoreData does? It lets you build objects linked to each other but handles all of the joining and syncing of the data for you to keep the object model in mind. In the same vein will you be creating a Swift client?
  • 1st1 5y ago
    I'm not too familiar with the CoreData API, but from a quick googling it seems like this is some sort of an ORM on top of SQLite. We position EdgeDB as a database server, not a library, partly because you can interact with it from different programming languages. But we design our client library with focus on API composability, check out our edgedb-js library for example: https://www.edgedb.com/docs/clients/01_js/index https://www.edgedb.com/docs/clients/01_js/index As for the Swift, it would be great to have it one day. I have a counter question: how many of you use Swift to write server-side logic?
    • solarmist 5y ago
      Right, but conceptually the way you interact with it is the same. I'm not trying to belittle what you've done. I'm in fact very excited about it. And EdgeDB is very needed because it's just an Apple library currently. Conceptually, my impression is that EdgeDb is relational tables (highly-typed) queried, combined, and modeled as nodes in a graph/tree. Is that conceptually correct? I don't, but I would like to if I could deploy Swift code to Azure. I love Swift as a language.
      • danappelxx 5y ago
        Swift has a family of Docker containers and an (admittedly modest) ecosystem of backend frameworks. You can definitely run it on Azure :)
• geenat 5y ago
  These guys are from magic stack, they wrote the definitive async python postgres library, asyncpg. Very high quality library. Been keeping a close eye on Edge, had even considered it as a primary database, and probably will in the future!! As much as I adore the ergonomics improvements I really am more interested in the performance, replication, scalability story, with the likes of cockroach db reaching maturity in 2022. But as a postgres replacement in general, I would highly consider using edge.
  • 1st1 5y ago
    Thank you :)
  • tragictrash 5y ago
    Been searching for something just like this for my next moonshot project. Very excited!!!
  • evil-olive 5y ago
    they also wrote uvloop [0] which is fantastic and advances the cutting edge of what can be done with modern asyncio-based Python. I saw a ~3x improvement in the throughput of a microservice I wrote when I first tried it out years ago. currently at $dayjob we just use it by default in every Python service, whether or not we expect that service to be performance-critical. it's as close as you can get to having actual magic sprinkles that make your code go faster. 0: https://github.com/MagicStack/uvloop https://github.com/MagicStack/uvloop
• rakibtg 5y ago
  > EdgeDB is built on top of Postgres How it is a new database? Or an advanced orm?
  • colinmcd 5y ago
    We're working on a more comprehensive explanation of why EdgeDB isn't an ORM. Does EdgeDB do "object-relational mapping" under the hood — absolutely. The reason we try to distance ourselves from the category of ORMs is that the term "ORM" comes with a big bag of preconceptions that don't apply here. EdgeDB has: - Full schema model with indexing, constraints, defaults, computed properties, stored procedures - A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug. Most ORMS provide some sort of language-specific API for writing queries and generating SQL under the hood—that's dramatically different than providing a new query language. - A full type system, grammar, set of functions and operators, etc. A set theoretic basis for all expressions in EdgeQL. https://www.edgedb.com/docs/edgeql/sets https://www.edgedb.com/docs/edgeql/sets - A set of drivers for different languages that implement our binary protocol. EdgeDB is a new abstraction built on a lower-level abstraction: Postgres. Both indubitably fit any reasonable definition of "database".
• radicality 5y ago
  I only glanced through this, but would you say there’s some vague similarities (ignoring the distributed/caching aspects) to Facebook’s TAO here? For example, as a user of this, would I have to care about the Postgres schema, or is that abstracted away from me? (Tao uses mysql and stores graph data as pretty much key/value pairs, and then a layer on top to query it)
  • RedCrowbar 5y ago
    There are similarities with TAO and it's not a coincidence. Facebook engineers recognized that a better data abstraction and API was needed for productivity. EdgeDB follows the same logic. > would I have to care about the Postgres schema, or is that abstracted away from me? EdgeDB takes care of everything for you. You wouldn't know it's Postgres underneath unless we told you.
  • 1st1 5y ago
    We fully manage the underlying SQL schema for you, it's abstracted away (which will allow us to pull some tricks when we eventually introduce live schema migrations). I haven't worked at Facebook so I'm not super familiar with TAO, only heard about it from my friends. But sometimes I pitch EdgeDB as a database with which you don't need to build your own TAO at your company. we give you much more capabilities than a typical database.
• tzahifadida 5y ago
  Orientdb is also sql like syntax graph database with way more traction. So this is not the first attempt at this type of databases.
  • 1st1 5y ago
    I'll cite my other comment from this thread: OrientDB positions itself as a multi-model NoSQL database. Where's EdgeDB positions itself as a relational database and a successor of SQL.
• deleted 5y ago
  [deleted]
• hackandtrip 5y ago
  I know benchmarking DB is very hard and pretty much nonsense, but do you have any idea / production use cases of EdgeDB at large scale? Did you see a performance drawback given from the higher abstraction, and the EdgeDB stateless client between the app and postgre?
  • RedCrowbar 5y ago
    We've got some benchmarks in an earlier blog post [1]. EdgeDB is designed to do its job validating and compiling your schema and queries and then get out of the way. In other words, once a query was first parsed and compiled, the cost of the next trip via EdgeDB would be similar to that of pgbouncer, i.e. we'll simply send the compiled SQL to Postgres and proxy the results back to the client. This is why our data protocol uses Postgres framing and encoding. [1] https://www.edgedb.com/blog/edgedb-1-0-alpha-1 https://www.edgedb.com/blog/edgedb-1-0-alpha-1
• dawei67 5y ago
  This looks like a better prisma. Too bad its using postgresql. It will not scale. Do you plan to develop your own backend or support others one ?
  • slx26 5y ago
    I don't have any strong opinion about it, but I have the same question: is it possible that in the long term the backend will be replaced by a custom one? And if not, what is the postgres backend bringing to the table that's difficult to replace? Sure there will be some friction between edge's model and the way it has to be internally expressed in postgres? Edit: oh, a relevant reply https://news.ycombinator.com/item?id=30293064 https://news.ycombinator.com/item?id=30293064
• joefigura 5y ago
  Very exciting product, congratulations on the launch!
  • 1st1 5y ago
    Thank you!
• spankalee 5y ago
  This query language looks really nice! I wish GraphQL were more like this and considered built-in features like where clauses and cursors, instead of having to add those over the top with loose conventions.
  • 1st1 5y ago
    GraphQL is great for what it was designed for. It just was never designed to be a querying language with analytical capabilities, like EdgeQL.
    • spankalee 5y ago
      Forget analytics, it can't even do pagination. That really limits the benefit of being introspectable.
      • 1st1 5y ago
        Yeah, true. FWIW with EdgeQL you can also introspect all aspects of your schema.
• iddan 5y ago
  This is so exciting. We can definitely do better than SQL in 2022 and EdgeDB is a step in the right direction. Been using Prisma[0] in production in the past year and a half (which takes the same approach as EdgeDB but currently works for TypeScript and Golang) and I'm so happy. [0]: https://www.prisma.io/ https://www.prisma.io/
  • adevx 5y ago
    Prisma + Typescript is such a productivity boon, auto completing all query options and database fields. And the results fully typed.
  • colinmcd 5y ago
    Prisma did a lot of things right, and we have a ton of respect for the team over there! At the end of the day, building a good, idiomatic API for doing CRUD operations is a hard problem. But building an entirely new query language that fundamentally solves some underlying design flaws and usability issues with SQL is a whole other level of hard. With EdgeQL, we conclusively solved a lot of these fundamental issues. Now, we're able to use EdgeQL as the foundation of our query builders, which is a huge advantage. We built the first version of the TypeScript QB in ~4 months) and it immediately leapfrogs all the major ORMs in power & expressiveness. But that's only possible because the hard work of designing EdgeQL was already done. We'll be working on communicating how our query builder works and how it compares to ORMs in some of upcoming posts, stay tuned.
• TheSpiciestDev 5y ago
  I feel like a graph database is a solution to an issue I've faced (and, continue to face) and it may just be because that I haven't spun one up and tried or that the documentation/examples don't stick out. But could someone confirm my feeling? If my feeling is correct, I'd enjoy verifying it with EdgeDB or the like. My example/requirement: I have a user wanting to find best-matching blog posts. Every post is tagged with a given category. There could be 100+ categories in the blog system and a blog post could be tagged with any number of these system categories. A user wants to see all posts tagged with "angular", "nestjs", "cypress" and "nx". The resulting list should return and be sorted by the best matches, to those of least relevance. So, posts that include all four tags should be up top and as the user browses down the results, there are posts with less matching tags. What I've seen with SQL looks expensive, especially if you search with more and more tags. I may just not know what to search for though, re. SQL. Is there a query against a graph database that could accomplish this?
  • rmbyrro 5y ago
    Thanks for posting this. Kind of comment that adds value to the discussion by illustrating how a piece of tech can or cannot be useful. I just happen to have a very similar requirement to yours and was also wondering.
  • klohto 5y ago
    Is it though? Simple IN with an ORDER BY on the same match will return the correct ranking. More info on ranking here https://www.postgresql.org/docs/current/textsearch-controls.html#TEXTSEARCH-RANKING https://www.postgresql.org/docs/current/textsearch-controls....
    • d_watt 5y ago
      Am I right in reading this as the parent comment envisioning a “post” table and a “tag” table, and you’re suggest the “post” table just have a “tag” column?
      • klohto 5y ago
• skybrian 5y ago
  It's a good sales pitch, but it's not immediately clear what the terms are. I see that there is a company behind this, that there's also a Github repo, and it appears you can install something without paying. But is it entirely open source? If not, what are they selling? What kind of business is this?
  • RedCrowbar 5y ago
    We will run and support EdgeDB for you. Here's an expanded answer: https://github.com/edgedb/edgedb/discussions/3377 https://github.com/edgedb/edgedb/discussions/3377
  • colinmcd 5y ago
    Everything is fully OSS: the database, our client libraries, our CLI. There's a company behind it (I'm an employee) which will make money with a cloud hosting platform, similar to Mongo. We're calling that EdgeDB Cloud and it's still under development. Though you can self-host too on any major cloud. [0] [0] https://www.edgedb.com/docs/guides/deployment/index https://www.edgedb.com/docs/guides/deployment/index
• vander_elst 5y ago
  How does this compare against neo4j? When should I choose one instead of the other?
  • 1st1 5y ago
    I replied to a similar comment here: https://news.ycombinator.com/item?id=30291290 https://news.ycombinator.com/item?id=30291290
• ei8ths 5y ago
  how well does it scale?
• ei8ths 5y ago
  How well does it scale? Any benchmarks and performance metrics?
• quickthrower2 5y ago
  Nice. This seems so pragmatic - making something to make developers lives easier rather than doing something clever. I could see myself using this in personal projects. (My day job is heavily MS so wont be using it there)
• totony 5y ago
  EdgeQL seems like a custom graphQL. Any reasons you did not follow dgraph's DQL or graphQL-compatible language? https://dgraph.io/docs/get-started/ https://dgraph.io/docs/get-started/
  • 1st1 5y ago
    GraphQL doesn't have any syntax for expressions, like 1+1 is inexpressible with GraphQL. Once you add support for arbitrary expressions, functions, etc you start departing from GraphQL to something that looks surprisingly similar to EdgeQL :)
• mstade 5y ago
  I can’t find anything in the docs on security. PostgreSQL has a pretty solid authorization story with row level security etc. Does EdgeDB provide any similar authorization mechanisms to ensure only data the user is entitled to is returned in queries?
  • RedCrowbar 5y ago
    Security policy will be part of the next release. See draft RFC [1], although note it's likely not going to be the final syntax. [1] https://github.com/edgedb/rfcs/blob/865bc48f4050ced99447bd77a5039f5d34fcb8b2/text/1011-query-rewrite.rst https://github.com/edgedb/rfcs/blob/865bc48f4050ced99447bd77...
• xrendan 5y ago
  What's the sort of timeline on GIS extensions? Great work btw, I've been following since the alphas and I'm excited to try it out :)
  • RedCrowbar 5y ago
    We need to figure out the formal API and packaging format for extensions. We're working on it.
• danr4 5y ago
  Looks very good. Who uses it in production?
• mbesto 5y ago
  first commit 2009, so we're roughly 12 years later. Whats the saying? It takes about 10 years to create a reliable DB? Good on you guys. Looks super interesting.
  • RedCrowbar 5y ago
    It's a long story :-) https://www.edgedb.com/blog/building-a-production-database-in-ten-years-or-less https://www.edgedb.com/blog/building-a-production-database-i...
    • didip 5y ago
      I always appreciate the historical journey why someone made X the way it is. Thank you for sharing.
• Sytten 5y ago
  Congrats on the launch! The code seems to be Apache 2.0 which opens the door to AWS or other big clouds just hosting the service instead of people using your cloud service. Are you guys planning to change the license to prevent that? On a tangent note, I find it is honestly annoying to have to maintain a separate account/authorization/vpc connection just because I want to use a database. I would much rather startups work with cloud providers to offer it natively or we invent a better way to interoperate with clouds. The explosion of small "cloud" that offer one service each isn't pleasant to work it especially when they don't have a terraform provider.
  • 1st1 5y ago
    Re license we have an answer for you here: https://github.com/edgedb/edgedb/discussions/3377 https://github.com/edgedb/edgedb/discussions/3377 Re second point you can deploy edgedb to your cloud of choice. As for working with cloud providers to make integration better for the user, it's a bit too early for us to comment.
    • Sytten 5y ago
      Thanks! Cloud of choice is great, also need region and AZ of choice too for any serious production database. What is killing performance is round trip time to the DB. The language seems to help on the number of round-trips so that's good.
      • 1st1 5y ago
        > The language seems to help on the number of round-trips so that's good. Yep, you got it! :)
  • colinmcd 5y ago
    A lot to unpack here. 1. If other clouds want to offer a hosted EdgeDB offering, they can do so. We'll have a tight integration with the `edgedb` CLI and we're confident we can beat them on the developer experience which is our #1 priority. 2. We'll likely use GitHub for auth though this isn't set in stone yet. We're still planning out the workflows surrounding EdgeDB Cloud. 3. As for the explosion of cloud silos—that's a very real phenomenon with a boring reason: hosting is one of the few ways to make money building OSS software. There are preposterously valuable OSS frameworks + libraries that haven't made anyone a cent. We implemented "one-click" deploy buttons for the major clouds to the extent it was possible to do, but for fully open-source companies like EdgeDB there's aren't many routes to sustainability outside of paid hosting.
• syrusakbary 5y ago
  I'm so happy for you guys, I'm wishing you great success. Since the first first version of uvloop I've been excited about MagicStack and I couldn't be more excited about EdgeDB since it has the same magical minds behind. Here's what I think makes EdgeDB special: it's a DB that replaces the tediousness of ORMs with a better core that can be cross-language / cross-platform. I've implemented tons of APIs, first REST, then GraphQL all of them on top of ORMs (Django, Peewee, SQLAlchemy, Mongoose and more). When prototyping was great, but scaling them became quite challenging, specially if you want to have a performant outcome when retrieving data. EdgeQL is an incredible useful abstraction that will prove itself in a few years. Long life EdgeQL. Keep up the good work!
  • 1st1 5y ago
    Aww, thanks!
  • tomjakubowski 5y ago
    > it's a DB that replaces the tediousness of ORMs with a better core that can be cross-language / cross-platform Does it compare to RethinkDB in this regard? The "fluent" native query language, ReQL, was one of its best parts.
• The_rationalist 5y ago
• solairephantom 5y ago
  Thank you for the monumental work you guys put into this! Looks very interesting, and something I would like to try out. One quick question - I see that you have a Rust client, however it's marked WIP, how usable is it in its current state? Any idea on a timeline of it becoming an official binding?
  • RedCrowbar 5y ago
    It's usable and functional, because we use it in our CLI. It's WIP, because we haven't yet committed to an API, especially in async. Rust is a bit hard in that department :-)
• eyelidlessness 5y ago
  I’ll add to the positivity: this is the first time I’ve ever found a “we can do better than SQL” compelling. It’s easy to understand what it’s doing with a variety of known quantities. It solves a difficult problem elegantly. It has 100% overlap with the goals I want it to have. It’s designed to be usable with minimal fuss. It does really a good job of portraying itself as magic (it will be awesome to use) without portraying itself as magic (it explains itself in terms of already knowable tools and how it leverages their strength). I do have a couple minor quibbles: - Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. - Some of the language in this post are in CAP theorem territory but neglect to directly address that. I’d like to see how client usage compares with direct Postgres usage (idiomatic for each insofar as such a beast exists) in a Call Me Maybe. I know that’s a lot to ask in a 1.0 announcement four years in the making, but I hope it’s a priority to get this in front of Aphyr. Edit: oh and I definitely look forward to this being further distinguished from an ORM, because even though I can see the blue and black dress my mind keeps switching it back to gold and white.
  • RedCrowbar 5y ago
    > I’ll add to the positivity Thank you! > Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front. We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so we have the ability to steer these into a read-only transaction, though this isn't implemented yet.
    • eyelidlessness 5y ago
      It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses: - The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those. - The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected by, the client. When automated by an abstraction layer, this can become pathological pretty easily depending on usage patterns. The most realistic alternatives are to provide a lower level abstraction (eg “I don’t want your guarantees, I want your errors”), or to provide other isolation options (eg “I don’t want your guarantees, I want my errors”). But there may well be opportunities here because EdgeDB knows as much as it does about the schema, and positions itself as a SQL replacement rather than a companion so it can potentially optimize for at least some of those cases at query time. That sounds complex enough to boggle my mind, but if y’all are up to it I’ll be excited to see how it goes!
• jitl 5y ago
  Congrats on the milestone! I've been following for a while - awesome to see the progress you've made. Q: What are your plans for sharding / scale-out? At Notion, we run ~480 logical schemas spread across ~32 Postgres databases [1]. Our data model [2] (sorry for the blog post spam) has a recursive / graph-like structures, and we make use of columns or jsonb attributes like `{ table: Table, id: UUID }` which sounds like your polymorphic links feature. It seems like EdgeDB's model lines up well with how we already use our database. I did a quick cmd-f here, on the linked announcement, and in your docs looking for "shard" and "scale" but didn't find any relevant results. Postgres needs a Vitess! Q: Do you have plans to support EdgeQL embedding or SQLite? I am always looking for a way to compile "better than SQL" languages down to SQL. I like Datalog in this area because it's a composable way to define relationships/facts/derivations but no one is putting serious business effort to this idea (honorable mention to logica [3]). EdgeQL also fits the bill -- queries aren't logical, but they are composable -- plus looks easier to teach than most Datalog variants. I took a peek in the repo and saw that a few EdgeQL components are written in Rust [4]; are you considering porting more logic to Rust? That would make EdgeQL much more embeddable - it could run in WASM or linked into an Android/iOS app. My pie in the sky dream is to use a single composable query/logic language to define all my relations and queries, and then compile that stuff so it works the same on both the client, server DB, and data streams (for incremental materialized views, ideally on both client & server). If EdgeDB had a Lite version that ran on SQLite, we'd be 66% of the way there. (To get the materialized view bits on the server, a mad scientist might already be able to point EdgeDB at Materialize [5]) [1]: https://www.notion.so/blog/sharding-postgres-at-notion https://www.notion.so/blog/sharding-postgres-at-notion [2]: https://www.notion.so/blog/data-model-behind-notion https://www.notion.so/blog/data-model-behind-notion [3]: https://opensource.googleblog.com/2021/04/logica-organizing-your-data-queries.html https://opensource.googleblog.com/2021/04/logica-organizing-... [4]: eg https://github.com/edgedb/edgedb/tree/master/edb/edgeql-parser/src https://github.com/edgedb/edgedb/tree/master/edb/edgeql-pars... [5]: https://materialize.com/docs/overview/architecture/ https://materialize.com/docs/overview/architecture/
  • RedCrowbar 5y ago
    > Congrats on the milestone! Thanks! > Q: What are your plans for sharding / scale-out? Sharding is planned, though there is no set design yet, this area is in early research phase currently. Thanks for sharing your experience by the way! Learnings from the field definitely help. A traditional read replica scale-out is already supported and we are building integrations with Postgres orchestrators (for failover, replica discovery etc). Oh, and automatically routing read-only queries to read replicas (with some controls for lag) is something that we plan as well. > Q: Do you have plans to support EdgeQL embedding or SQLite? Possibly. Depends on the application and performance expectations :-) PostgreSQL is really special in its ability to deal with complex queries. We already have a toy EdgeQL interpreter in the codebase [1], which is mostly used to quickly prototype syntax and validate semantics. It would be great to scale it up to something that can work with persistent stores (even if dumb and slow). > are you considering porting more logic to Rust? Yes, that the long term plan. [1] https://github.com/edgedb/edgedb/blob/master/edb/tools/toy_eval_model.py https://github.com/edgedb/edgedb/blob/master/edb/tools/toy_e...
• thejosh 5y ago
  Looks great, but the example for SQL looks kind of bad. Is that how pg does things? I thought "modern SQL" used CTEs and other fun features, or this that not a thing for pg as much as say snowflake?
  • wafer-bw 5y ago
    Yea the SQL example looks like the intentionally made it way worse than it needed to be...
    • 1st1 5y ago
      It was taken from Elvis' talk. Here's the video explaining how we get to this query and why: https://youtu.be/WRZ3o-NsU_4?t=1892 https://youtu.be/WRZ3o-NsU_4?t=1892
• 0x202020 5y ago
  Poking a bit at the documentation, I see like/ilike but are there plans for text search/trigram capabilities? Recently I’ve been working with lots of different entities that have searchable properties and exploring searching across different elasticsearch indexes to do “JOIN” like operations but have been exploring Postgres (and related) solutions for better “JOIN” support out of the box
  • 1st1 5y ago
    Yep, we have plans for that. We are exploring if it would be feasible to make it possible to plug-in external engines like elastic and make that integration totally automatic, enabled with a simple annotation in the schema.
    • 0x202020 5y ago
      Even better then I would have thought, thanks! I’ve primarily dealt with Elasticsearch/Solr in my career, so jumping into the way searches work in Postgres with various native support and plugins is, interesting to say the least. Maybe I just need to break my Lucene roots
• person3 5y ago
  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 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. > The true source of truth I'm not sure why this means EdgeDB is better. Tons of applications use a traditional or cloud SQL database as the source of truth right now. This section seems to imply with microservices you no longer have a single source of truth. But if they're trying to say a microservice system should instead us a single common database that breaks separation of concerns and moves us into an annoying situation where you have a bunch of services communicating via a shared database. > Not just a database server It sounds like they have a solid client, which is awesome. > Cloud-ready database APIs > The vast scale of modern application deployments requires that inelastic computing resources are managed very carefully. Until cloud-native databases reach complete functional and performance parity with traditional databases, we will have to contend with the fact that the database is a scarce resource. This used to be true, but is definitely no longer true. Cloud-native databases are everywhere and incredibly common. See any major cloud, https://www.cockroachlabs.com/ https://www.cockroachlabs.com/, or any of the tons of other database solutions. It's great to see a new database coming out - innovation in the space is super important. However this announcement reads like marketing speak, and is light on the details. When I see a new product I want to hear things like: - about how it scales - what the architecture is - why is it stable and trust-worth enough to put my data on - is it multi-node? How did they make it serializable? - how fast is it? Performance is super important. Based on their website it seems like a thin skin over postgresql. If that's the case I'll just use postgresql. If it's a clustered new and advanced database, then I'll be wary about trusting it for anything real.
  • 1st1 5y ago
    >> 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. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation. > > The true source of truth > I'm not sure why this means EdgeDB is better. <..> This section implies that EdgeDB's schema allows to specify a lot of meta / dynamically computed information in it. And soon your access control policies. Take a look at the work-in-progress RFC [2] [3] to see how this is more powerful, then say, Postgres' row level security. > > Not just a database server > It sounds like they have a solid client, which is awesome. Also lightweight connections to the DB so that you can have thousands of concurrent ones without load balancers, built-in schema migrations engine, and many other things. In fact we have so much that it's challenging what to even highlight in a blog post like the 1.0 announcement. > Cloud-ready database APIs > This used to be true, but is definitely no longer true. Cloud-native databases are everywhere and incredibly common. See any major cloud, https://www.cockroachlabs.com/ https://www.cockroachlabs.com/, or any of the tons of other database solutions. Not to pick on CockroachDB (they have an amazing product and company, we love them), but you should benchmark local install of Postgres and Cockroach to see yourself that scalability still has a significant cost in performance. [1] https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-server https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-s... [2] https://github.com/edgedb/rfcs/pull/49 https://github.com/edgedb/rfcs/pull/49 [3] https://github.com/edgedb/rfcs/pull/50/files https://github.com/edgedb/rfcs/pull/50/files
• nh2 5y ago
  Sounds pretty cool! Questions: 1. What is the story for replication currently? Can I use EdgeDB with Posgres replication tools like Stolon or Patroni, running EdgeDB against the proxy they expose? Or does EdgeDB plan/need to have its own replication? Googling this, I found this previous HN post (https://news.ycombinator.com/item?id=19640689 https://news.ycombinator.com/item?id=19640689) saying: > Tooling for that will be coming in the next few alpha releases. 2. "A builtin migration system that can reason and diff schemas automatically or interactively" How do you deal with the fact that Posgres does not offer transactional DDL (e.g. ALTER TABLE)? In our Posgres, we had to use advisory locks around migrations to avoid concurrent schema changes invoked by concurrently starting servers which run migration.
• didip 5y ago
  Won't Python be a total bottleneck from compute perspective and concurrency perspective?
  • 1st1 5y ago
    We know a thing or two about concurrency and Python. Take a look at our blog post [1] touching on what we do and how. [1] https://www.edgedb.com/blog/building-a-production-database-in-ten-years-or-less https://www.edgedb.com/blog/building-a-production-database-i...
• stevefan1999 5y ago
  I'm disappointed on you open sourcing it. Now I'm not against OSS movement and in fact I'm working at a company doing exactly this, but releasing your bread-and-butter as an open source project leaves you vulnerable to peer plagiarism. Instead, you should just release the core version so others will build an open ecosystem around your mainline product. This will secure your market fundamentals by making sure no one could overshadow you especially in a fiercely competitve market of database. So please stop open sourcing too much, I don't want to see the same ill fate again and again for great products like RethinkDB (and its downfall) that could change the world
  • 1st1 5y ago
    > Instead, you should just release the core version so others will build an open ecosystem around your mainline product. To be clear EdgeDB is the core version, albeit a large core. We have many ideas about value-adds. But the goal for open sourcing it is indeed to foster an open ecosystem.
• chrismarlow9 5y ago
  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.
  • mb7733 5y ago
    How is it like MapReduce at all?
• pier25 5y ago
  Why is it called Edge though? I immediately assumed it was some kind of distributed db running at the edge but it seems this is not the case.
  • sixo 5y ago
    Probably in the sense of a graph edge.
    • 1st1 5y ago
      Yes, spot on.
• cliffordfajardo 5y ago
  Where does full text search fall into the picture / current query language? Do I need to drop down to writing SQL for that? When do you drop down to SQL / where does the boundary end for edgeQL?
• xeromal 5y ago
  This looks phenomenal guys. I've read a bunch of these Show HN posts over the years and I struggle to stay engaged on most of them. They always lean towards highly technical that makes my small brain smooth over or so much marketing speak that I have no idea what's going on. Your post was short enough to comprehend in one sitting, you have an example near the beginning and you make your case clearly. I love that you used Postgres as a layer and I think that set you up for success. You have me excited and I'm pretty pumped to use edgedb in one of my idea projects just to get a feel for how it works. Congrats!
  • 1st1 5y ago
    Thanks. Please report back your experience!
• allisdust 5y ago
  Great project. Can this be used from rust somehow?
  • 1st1 5y ago
    An official Rust client is in the works.
• imachine1980_ 5y ago
  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
  • your_challenger 5y ago
    > they'll run and support EdgeDB infrastructure for you (a managed EdgeDB service is coming) https://github.com/edgedb/edgedb/discussions/3377 https://github.com/edgedb/edgedb/discussions/3377
• diimdeep 5y ago
  Hi. Is there architecture document explaining all moving parts ? And tracing what is happening from beginning of query to result?
  • 1st1 5y ago
    We don't have a doc on internal architecture, but we discussed it during our live-streamed launch event today: [1] > And tracing what is happening from beginning of query to result? EdgeDB exposes a Prometheus endpoint with a bunch of metrics. We don't have a public API for tracing individual queries yet. [1] https://youtu.be/WRZ3o-NsU_4?t=5317 https://youtu.be/WRZ3o-NsU_4?t=5317
• fuddle 5y ago
  This looks pretty cool. I'd be interested to hear when the Rust bindings will be production ready: https://github.com/edgedb/edgedb-rust https://github.com/edgedb/edgedb-rust
• treve 5y ago
  I wonder how EdgeDB talks to postgres. Does it speak the Postgres protocol and translate the queries, or is it more of a deeper integration in to the storage layer? Very interested in this! I've been wanting to build a generic HATEOAS server and this feels like this might be the right database!
• tomerbd 5y ago
  For this query to work which is shorter than SQL select Movie { title, rating := math::mean(.ratings.score) actors: { name } order by @credits_order limit 5, } filter "Zendaya" in .actors.name Do I need to write some metadata layer so this higher level query would know what's going on? Similar to LookerMl?
• tomerbd 5y ago
  When intellij datagrip supports it I'll try it
• zmmmmm 5y ago
  Hmm, no JVM or .NET support ... seems problematic for any widescale adoption at this point. Are there fundamental reasons why this is problematic or just not got around to it? (And, is it likely to be possible to build it against standard interfaces like JDBC - or is it too different?)
  • rahkiin 5y ago
    I wonder this too. The examples I see seem to work best with a dynamically typed language. Is there an example on how this API would work for statically typed languages? Or even languages that don’t like Nulls like Rust or Swift (making everything an optional is not great)
    • your_challenger 5y ago
      They have a golang client. And there was an attempt to write a Java client[1]. Someone could help ShaileshSurya (the java client maintainer) [1] https://github.com/ShaileshSurya/edgedb-java https://github.com/ShaileshSurya/edgedb-java
• c4m 5y ago
  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 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?
  • ignoramous 5y ago
    > What's a good way to develop a mental model about what's happening under the hood in EdgeDB? 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 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 https://en.wikipedia.org/wiki/Physical_schema [1] https://en.wikipedia.org/wiki/Conceptual_schema https://en.wikipedia.org/wiki/Conceptual_schema [2] https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
    • c4m 5y ago
      I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
      • msully4321 5y ago
        I talked a bit about this in my release day talk (https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s), but: * Every edgedb type has a postgres table * "single" properties and links are stored as columns in that table (links as the uuid of the target) * "multi" properties/links are stored as a link table So it's basically just translated to a relational database in normal form
• nlnn 5y ago
  Does it include (or have planned) any features relating to full text search, more specifically for mixing ranking/search with graph queries? One use case I have (solved by some current graph DBs) is performing a complex full text search (boolean operators, stopword removal, fuzzy matching etc.), which alters search ranking based on graph properties (e.g. a node with more edges might get a reduction in score, the root of a tree might get a boost, etc.). I'm still going through the tutorial, so haven't got to grips with what the DB is capable of yet.
• thehyphen 5y ago
  Congrats on the launch. I watched the live stream yesterday. I'm particularly excited about the HTTP and the GraphQL interface. This could potentially mean no need for a backend. One thing I am curious about it the authorization part of it - how can I limit the result set, similar to Row Level Security in Postgres?
• yhoiseth 5y ago
  Congrats with 1.0. A couple of things I’m curious about: 1. How does EdgeDB compare to Supabase? Thinking both of realtime functionality and row-level security. 2. If I was to use EdgeDB instead of Django, how would I go about it? In other words, how can I set up a batteries-included, server-side web app?
• defanor 5y ago
  > This is why we wrote (and will continue writing) full-featured first-party database client implementations for common programming languages (currently available for Python, JavaScript/TypeScript/Deno, and Go). Why no C API? Pretty much every language has a C FFI, PostgreSQL's libpq is in C too, and then it's easy to make bindings from other languages. But with a few individual implementations in other languages it's not as easy to use from more languages. Always makes me to wonder about these decisions when I see projects heading that way. Unrelated to the subject, but the text on the website is #B3B3B3 on #FFF, which is hard to read as is, and violates WCAG recommendations. When overwriting it with a custom CSS, it's visible that headings have weird margins, covering parts of text before them. While looking for more, I noticed that the website suggests to `curl | sh` things in the introduction, which is quite awkward too (and a subject of light flamewars), adding another barrier. The brief project description made me to wonder how well it abstracts out PostgreSQL (and how to work with the databases it creates via PostgreSQL itself, if it's possible at all, how to debug it when things will go wrong), but after brief skimming there's no PostgreSQL bits in sight: just a special shell, a dedicated language, its own drivers. Which is a bit scary. Neither have I found a description of its graph-relational model, how it's built on top of PostgreSQL, how one can be sure that it'll work more or less smoothly, how things like profiling are done (or is it designed to never need explicit profiling/optimization?), is there more to it than PostgREST-like interface abstracting out the SQL bits for DDL too. Looks like an interesting project overall though.
• einpoklum 5y ago
  > Powered by PostgreSQL. You might need to worry about this in two senses: 1. Graph constructs aren't first-class citizens in the backend. Various potential performance improvements will necessarily be missed. 2. PostgreSQL is ok/good for transactional work, not good for analytical work, like columnar DBMSes.
• golondon 5y ago
  Hi, looks really great! Thanks for this great piece of tech! I have a question regarding the migrations, in the website you say it's safe to run them with automated flow, we know it uses Postgres under the hood and we know that sometimes migrations on large datasets can cause downtime in the database clusters. How do you handle them? I guess since you don't have a backing "users" table for a "User" model adding / removing fields is not actually happening the same way it happens in a normal relational database, thus it's not a blocking or resource consuming operation for you?
• Ambix 5y ago
  I've worked with ArangoDB recently and very much liked their AQL. How Edge compares with Arango?
• da39a3ee 5y ago
  Arggh why is "order by" two space-separated words in their language? If we're going to replace SQL the silly 1960s pseudo-English syntax is one of the things we want to get rid of, not retain.
• jamesfisher 5y ago
  FYI: your homepage makes my fan start up. Macbook Air, 2020. Chrome reports 30% on GPU process.
• RamblingCTO 5y ago
  I didn't have a very in-depth look, but it looks like you try to solve a lot at once. So I could replace graphQL and permissions with just edgeDB? Sounds nice, but I'm sceptical. And edit: why is there no Java/Kotlin client?
• brainbag 5y ago
  I'm skeptical of any fancy new database, because they have always been disappointing in one way or another, but this looks really promising! ORMs work fine for relational data, until there's a lot of edge data on the joins. I looked at the docs on mobile and couldn't find an answer, how does EdgeDB handle data on joins? E.g. GraphQL "connection" types with edges.
• hotfixguru 5y ago
  If anyone makes this work with heroku Postgres, let me know! I started a container and connected it, but instantly got an email from heroku telling me i had 19500 of my 10000 rows, and 215 tables. Not really any hobby-project viable priced hosting options in their documentation.
• shalabhc 5y ago
  EdgeQL looks really nice. I do think this will be somewhat hard to sell because at small scales SQL and basic ORMs mostly work and have less lock-in. At large scales folks also want a lot more operational features like scaling out, control of the underlying schema for performance reasons, relaxing some constraints for horizontal sharding, and so on. I think EdgeQL (and the data model) has potential for being a lot more than accessing the database. For example, you could have a distributed system use this data model across various typically replicated data stores - include all caches and "materialized views" of various kinds. Extend EdgeQL to define various caches and computed values from the core schema. Then you could use it to represent querying the same data but with different freshness. Now this becomes a compelling idea. Essentially it gives you a well defined way to declare and manage various computed values, laggy caches without having to manually implement all that coordination.
  • shalabhc 5y ago
    To add a specific example. A common pattern is 'put some objects in memcache' in front of the DB. Imagine if you can: 1. define a view representing the object fields you want to cache 2. define eviction and properties of the cache 3. use queries to query either the cache or the db Specifically, do all of the above using edgeql and not have to write the cache consistency or serialization/deserialization logic.
• TrapLord_Rhodo 5y ago
  Any timelines on when i can use this with rust? I love this syntax. Edit: Wow, after starting to read the book you guys have done a fantastic job of making it a joy to learn. Learning a database technology by following dracula? amazing. PLEASE PLEASE PLEASE giving this first class support in rust. The select statments reminds me of structs and you even have enums.
• dcsan 5y ago
  I love the look of this, but I've been burned by going all in on exciting projects before (rethink, merb,...) It might be a good idea to add some more info on the team behind, if they have funding to continue etc. MagicStack and uvloop are really worth connecting the dots with.