pREST VS dgraph

In a previous post, I published an example with PostgREST on YugabyteDB. Here is another one: pREST opens a REST API to PostgreSQL. YugabyteDB is a PostgreSQL-compatible Open-Source Distributed SQL database. It adds horizontal scalability to applications built for PostgreSQL. Let's see how it integrates with pREST.

Pretty sure I started with this: https://github.com/prest/prest/blob/main/cmd/root.go

And from there you can execute your own command and add handlers or other things as you wish.

Improve local tests execution — it is frustrating that someone wants to contribute and cannot run the local tests (we use e2e tests, making requests to prestd's own API), a way was implemented where the tests run inside docker using docker-compose;

With pRest, it is possible to create a RESTFul API to access the contents of a Postgres database in a fast and straightforward way. The project, written in Go, can be found on its official website and Github.

View on GitHub

Dgraph: A distributed and scalable graph database known for high performance. It's a good fit for large-scale graph processing, offering a GraphQL-like query language and gRPC API support.

Dgraph (GraphQL, DQL)

Have you tried dgraph.io?

DGraph – A distributed GraphQL database with a graph backend.

How does it compare to, say grakn (renamed https://vaticle.com/, I think?), or draph (https://dgraph.io/), or Ontotext's GraphDB (https://www.ontotext.com/products/graphdb/), or Datomic?

Consul Connect service mesh has a higher memory footprint, so on a small cluster with e5-medium nodes (2 vCPUs, 4 GB memory), you will only be able to support a maximum of 6 side-car proxies. In order to get an application like Dgraph working, which will have 6 nodes (3 Dgraph Alpha pods and 3 Dgraph Zero pods) for high availability along with at least one client, a larger footprint with more robust Kubernetes worker nodes were required.