SaaSHub helps you find the best software and product alternatives Learn more →
Edgedb Alternatives
Similar projects and alternatives to edgedb
-
supabase
The open source Firebase alternative. Follow to stay updated about our public Beta.
-
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
supabase-graphql-example
A HackerNews-like clone built with Supabase and pg_graphql
-
neon
Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage. (by neondatabase)
-
-
Prisma
Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
-
Sonar
Write Clean Python Code. Always.. Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.
-
-
-
trustfall
If GraphQL were more like SQL: a query language for any combination of data sources.
-
-
react-relay
Relay is a JavaScript framework for building data-driven React applications.
-
-
-
-
postgraphile
Execute one command (or mount one Node.js middleware) and get an instant high-performance GraphQL API for your PostgreSQL database!
-
-
ObjectBox Java (Kotlin, Android)
Java Database for Mobile & IoT - fast and lightweight
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better edgedb alternative or higher similarity.
edgedb reviews and mentions
Posts with mentions or reviews of edgedb.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-07-28.
-
EdgeDB 2.0
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.
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.
-
GraphQL Is a Trap?
You have to do your own optimiser to avoid, for instance, the N+1 query problem. (Just Google that, plenty of explanations around.) Many GraphQL frameworks have a “naive” subquery implementation that performs N individual subqueries. You either have to override this for each parent/child pairing, or bolt something on the back to delay all the “SELECT * FROM tbl_subquery WHERE id = ?” operations and convert them into one “… WHERE id IN (…)”. Sounds like a great use of your time.
In the end you might think to yourself “why am I doing this, when my SQL database already has query optimisation?”. And it’s a fair question, you are onto it. Try one of those auto-GraphQL things instead. EdgeDB (https://edgedb.com) does it as we speak, runs atop Postgres. Save yourself the enormous effort if you’re only building a GraphQL API for a single RBDMS, and not as a façade for a cluster of microservices and databases and external requests.
Or just nod to your boss and go back to what being a backend developer has always meant: laboriously building by hand completely ad hoc JSON versions of SQL RBDMS schemas, each terribly unhappy in its own way. In no way does doing it manually but presenting GraphQL deviate from this Sisyphean tradition.
I read in the article that NOT having GraphQL exactly match your DB schema is a best practice. My response is “did a backend developer write this?”
-
How we sharded our test suite for 10x faster runs on GitHub Actions
Same idea, yeah. Unfortunately, in our case we couldn't use pytest due to complicated test setup, so we used a customized unittest runner instead.
-
GraphQL is now available on Supabase
EdgeDB [1] has indeed a rich GraphQL layer, but it's a very different project.
While it also builds on top of Postgres, EdgeDB replaces the entire relational database front-end. EdgeDB features a SQL replacement language called EdgeQL (analytical capabilities of SQL married with deep-fetching in GraphQL), a higher-level data model (tables -> object types), integrated migrations engine, a custom protocol with great performance & great client APIs, and many other things. Read more here [2].
(disclaimer: I'm EdgeDB co-founder)
-
EdgeDB 1.0
> 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_e...
> 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.
I'm curious how this squares up with what someone linked elsewhere: https://github.com/edgedb/edgedb/discussions/3403
> 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.
This would seem to be an opposing view of how coupled EdgeDB and PostgreSQL are. Which is it?
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 "references" 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.
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
[2]: https://www.notion.so/blog/data-model-behind-notion
[3]: https://opensource.googleblog.com/2021/04/logica-organizing-...
[4]: eg https://github.com/edgedb/edgedb/tree/master/edb/edgeql-pars...
-
A note from our sponsor - #<SponsorshipServiceOld:0x00007f160cf3e5c0>
www.saashub.com | 22 Mar 2023
Stats
Basic edgedb repo stats
14
10,696
9.5
about 5 hours ago
edgedb/edgedb is an open source project licensed under Apache License 2.0 which is an OSI approved license.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com