pg_jsonschema
edgedb
pg_jsonschema | edgedb | |
---|---|---|
15 | 19 | |
929 | 12,306 | |
1.6% | 1.0% | |
6.6 | 9.9 | |
19 days ago | about 9 hours ago | |
Rust | Python | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pg_jsonschema
-
Introducing pgzx: create PostgreSQL extensions using Zig
And lots of interesting extensions use it, like
https://github.com/tembo-io/pgmq
https://github.com/zombodb/zombodb
https://github.com/supabase/pg_jsonschema
-
Beyond SQL: A relational database for modern applications
> In other words, there is still a (lossy) translation layer, it just happens to be in the RDBMS rather than in-app.
It's not lossy if your application can guarantee a json <-> datatype roundtrip and the json is validated with jsonschema (generated by your application)
In Rust it's something like this
https://serde.rs/ to do the data type <-> json mapping
https://docs.rs/schemars/latest/schemars/ to generate jsonschema from your types
https://github.com/supabase/pg_jsonschema to validate jsonschema in your database (postgres). with this setup it's interesting (but not required) to also use https://docs.rs/jsonschema/latest/jsonschema/ to validate the schema in your application
-
FerretDB, a truly open-source MongoDB alternative
Pretty exciting!
What about optionally validating some columns with jsonschema? Perhaps using https://github.com/supabase/pg_jsonschema - is using other postgres extensions supported in FerretDB? (if not, maybe it's feasible to incorporate the code of pg_jsonschema in FerretDB?)
- Type Constraints in 65 lines of SQL
-
Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees
I'm not currently using it, but I'm strongly considering validating json in postgres with https://github.com/supabase/pg_jsonschema - which uses the https://docs.rs/jsonschema/latest/jsonschema/ Rust crate
So I'm not sure if my feedback is valid but, I sure hope that the jsonschema crate follows the spec! Otherwise I'll never use jsonschema but instead something-not-exactly-jsonschema. In other words.. you better not break anything.
-
Features I'd Like in PostgreSQL
Sounds dumb, but I want JSON field schema validation. I added a JSON column for flexible data, and although I'm happy with its flexibility, I kinda hope I can validate the JSON data structure. Recently I just found an extension [1] and will try soon.
[1] https://github.com/supabase/pg_jsonschema
-
Dynamic JSON schema validation, how can I do that in Postgres?
https://github.com/supabase/pg_jsonschema is new and looks good
-
Supabase Beta July 2022
Born as an excuse to play with pgx, pg_jsonschema is a solution we're exploring to allow enforcing more structure on json and jsonb typed postgres columns. Only 10 lines of code 😎
- GitHub - supabase/pg_jsonschema: PostgreSQL extension providing JSON Schema validation
- Show HN: Pg_jsonschema – A Postgres extension for JSON validation
edgedb
- EdgeDB – A graph-relational database with declarative schema
-
Beyond SQL: A relational database for modern applications
A new DB, with a new query language that's like "SQL done right"? This immediately reminded me of EdgeDB: https://edgedb.com/
Is there anyone here who knows enough about these two products to do a compare/contrast?
-
EdgeDB 3.0
The whole thing consists of these main parts:
1. SQL parser: https://github.com/edgedb/edgedb/tree/master/edb/pgsql/parse...
-
DuckDB 0.8.0
>relational no-sql
Do you mean something like edgeDB?[0]
Or do you mean some non-declarative language completely? I don't see the latter making much sense. The issue with SQL for me is the "natural language" which quickly loses all intended readabilty when you have SELECT col1, col2 FROM (SELECT * FROM ... WHERE 1=0 AND ... which is what edgeDB is trying to solve.
[0]https://edgedb.com/
-
Question about custom properties querying with the query builder
We need to land #3747, then something like this should work
- EdgeDB 2.0
-
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)
[1] https://github.com/edgedb/edgedb
[2] https://www.edgedb.com/blog/edgedb-1-0
-
EdgeDB 1.0
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?
What are some alternatives?
windmill - Open-source developer platform to turn scripts into workflows and UIs. Fastest workflow engine (5x vs Airflow). Open-source alternative to Airplane and Retool.
supabase - The open source Firebase alternative.
postgres-json-schema - JSON Schema validation for PostgreSQL
cockroach - CockroachDB - the open source, cloud-native distributed SQL database.
pgx - Build Postgres Extensions with Rust! [Moved to: https://github.com/tcdi/pgrx]
neon - Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage.
is_jsonb_valid - Native PostgreSQL extension to validate jsonb
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
pg_ivm - IVM (Incremental View Maintenance) implementation as a PostgreSQL extension
supabase-graphql-example - A HackerNews-like clone built with Supabase and pg_graphql
auth - A JWT based API for managing users and issuing JWT tokens
edgedb-rust - The official Rust binding for EdgeDB