Read the discussion on HN. A full-thread summary is not available yet.
geldata
gel
Python2018–2025
geldata / gel
gel
Gel supercharges Postgres with a modern data model, graph queries, Auth & AI solutions, and much more.
10Distinct people
21Mentions
0Explicit recommenders
14.2KGitHub stars
What to know before exploring
What it is
Gel supercharges Postgres with a modern data model, graph queries, Auth & AI solutions, and much more.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
Mentions over time
HN mentions by year21 dated mentions
Observed mentions: 2018-05-18 13:49:31 UTC to 2025-02-26 03:57:34 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
21 sourcesRERedCrowbar·Feb 26, 2025
You can use access policies [1] to emulate temporal data. See an example in [2]
[1] https://docs.geldata.com/reference/datamodel/access_policies
[2] https://github.com/geldata/gel/issues/4228#issuecomment-1208...
In EdgeDB is now Gel and Postgres is the futureEdgeDB – A graph-relational database with declarative schema
2 points · Open discussionThis is the beef of that compiler: https://github.com/edgedb/edgedb/tree/master/edb%2Fpgsql%2Fr...
In EdgeDB 3.0The whole thing consists of these main parts:
1. SQL parser: https://github.com/edgedb/edgedb/tree/master/edb/pgsql/parse...
2. SQL transpiler: https://github.com/edgedb/edgedb/tree/master/edb/pgsql/parse...
3. Wire protocol handler: https://github.com/edgedb/edgedb/blob/master/edb/server/prot...
In EdgeDB 3.0Where can I find instructions on how to build EdgeDB from source? Also, what is the difference between https://github.com/edgedb/edgedb and https://github.com/edgedb/edgedb-cli?
In EdgeDB 2.0Efficient transitive closure (aka link recursion) is something we plan to tackle soon (see https://github.com/edgedb/edgedb/discussions/2634 for some discussion on the topic).
In EdgeDB 2.0Alas, we have to wait until CockroachDB becomes a bit more capable SQL-wise. I gave a more elaborate answer in https://github.com/edgedb/edgedb/discussions/3403.
In EdgeDB 2.0That `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.
[1] https://github.com/edgedb/edgedb/discussions/3466
In EdgeDB 2.0Would 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.
[1] https://github.com/edgedb/edgedb
In EdgeDB 2.0EdgeDB [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
In GraphQL is now available on SupabaseI'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.
I don't see how this and what you're saying can both be true at the same time. Is EdgeDB tightly coupled to the implementation of PostgreSQL, or isn't it? Is there really a chance that EdgeDB could support other databases, or not really? I don't think there's anything wrong with the answers being "yes" and "no", respectively; that's actually what I'd expect. It would be more unusual to try to do this in an implementation-agnostic way.
In Show HN: EdgeDB 1.0> they'll run and support EdgeDB infrastructure for you (a managed EdgeDB service is coming)
https://github.com/edgedb/edgedb/discussions/3377
In Show HN: 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 i
Read the rest
s 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...
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
Read the rest
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...
[5]: https://materialize.com/docs/overview/architecture/
Re license we have an answer for you here: 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.
In Show HN: EdgeDB 1.0Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.