51–60 of 126 posts
Co-founder here - AMA.
Do you have any plans/aspirations in adding Temporal "immutable DB" functionality? [0] https://en.wikipedia.org/wiki/Temporal_database [1] https://github.com/scalegenius/pg_bitemporal/blob/master/doc... [2] https://github.com/ifad/chronomodel
[1] https://docs.geldata.com/reference/datamodel/access_policies
[2] https://github.com/geldata/gel/issues/4228#issuecomment-1208...
> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…
Also there are now databases purpose built for specific domains. E.g. if you are building a financial ledger I would way rather be interfacing with TigerBeetle than scaffolding an application-driven ledger around Postgres. https://tigerbeetle.com/ . If I am scraping giant amounts of data I would run far away from Postgres for other databases like Amazon Redshift.
Earlier quoted context omitted.
Have you tried drizzle? If so, what's your beef? (The only one I've had is lack of down-migrations)
Addressing your core question: Drizzle is a great ORM with a tastefully designed API—it's clearly a product of love. But it’s still an ORM, and it’s confined by certain design boundaries that come from being a library. For example, what if you want to use TypeScript, Go, and Python on your backend? Do you run three ORMs, each with different APIs? With Gel, you have one data model and a unified querying layer—the true…
Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table?
Using EdgeQL simple means I have another programming language at hand.
> EdgeDB has a robust type system that's most [sic] comprehensive that most ORMs
Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me.
> We've also built a query builder for TypeScript
Aha, so then... why not build a query builder for every language, just like with ORMs?
Sorry, not convinced. We would be better off by improving on SQL itself.
What is the self-hosting story I wonder? If we have our own Postgres db (placed in a specific region for compliance), and we put gel onto our k8s cluster as they state in their docs, does it work well? I assume this type of deployment is free right? What features are we missing from their cloud offering? GCP has very cool high availability, backup and monitoring features that I’d hate to loose if we move to their clo…
Fully supported, we have a guide for every popular platform [1].
> If we have our own Postgres db (placed in a specific region for compliance), and we put gel onto our k8s cluster as they state in their docs, does it work well?
If you're OK with managing Postgres and your own k8s you won't have a problem.
> I assume this type of deployment is free right?
Yes, and everything you need for that is Apache 2.
> What features are we missing from their cloud offering?
A couple:
1. Slow query log: it requires a custom C extension for Postgres (we wish it did not). It's part of Gel and is open source, but it's not allowed to deploy custom Postgres extensions, say, on AWS Aurora.
2. Integrations with Vercel [2] and GH. With our Cloud you get Vecvel Previews set up out of the box.
3. Convenience: we manage Gel Cloud and it's our headache to keep it running for you. :)
> Can you configure which region your data is in?
We're currently on AWS, but yes, you can configure a region, if you choose to use our cloud.
> Couldn’t really find that info in the docs / pricing pages.
Good point, I'll use this question as a template to add a Q&A there :)
[1] https://docs.geldata.com/resources/guides/deployment [2] https://www.geldata.com/blog/seamless-dx-with-vercel
> PostgreSQL's query planner/optimizer is decidedly state-of-the-art Postgres's cost-based planner is good, but it's a decidedly 1980s design, predating the famous but also outdated Volcano/Cascades systems (used by Microsoft SQL Server and CockroachDB and others). So much has happened in the field of query optimization in the last 30 years, very little of which has ended up in Postgres, I think. Postgres has gotten…
Also there are now databases purpose built for specific domains. E.g. if you are building a financial ledger I would way rather be interfacing with TigerBeetle than scaffolding an application-driven ledger around Postgres. https://tigerbeetle.com/ . If I am scraping giant amounts of data I would run far away from Postgres for other databases like Amazon Redshift.
Earlier quoted context omitted.
Addressing your core question: Drizzle is a great ORM with a tastefully designed API—it's clearly a product of love. But it’s still an ORM, and it’s confined by certain design boundaries that come from being a library. For example, what if you want to use TypeScript, Go, and Python on your backend? Do you run three ORMs, each with different APIs? With Gel, you have one data model and a unified querying layer—the true…
> Do you run three ORMs, each with different APIs? Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? Using EdgeQL simple means I have another…
I think... we're in a agreement? :)
EdgeQL doesn't have a NULL (it's a set-based language and NULL is an empty set, this tiny adjustment makes it easier to reason about missing data). And because it also has a more robust type system, allows for limitless composition and easy refactoring, it has far greater DX than SQL => you're more productive.
There's a footnote here: EdgeQL doesn't support some of the SQL capabilities just yet, namely window functions and recursive CTEs. But aside from that it is absolutely a beast.
> Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me.
Maybe, but I'm curious how you arrived to that conclusion. I assume you mean that using the power of a high-level programming language you can force ORM to complete submission and that's just not true. Most of the time you'll either have grossly inefficient multi-roundtrip query code (hidden from you) or let ORM go and use SQL. Obviously that's an extreme scenario, but it's surprisingly common in complex code bases and logic.
> Aha, so then... why not build a query builder for every language, just like with ORMs?
We are. We started with improving the network protocol (it does less round-trips than Postgreses and is stateless) and crafting client libraries for MANY languages. All client libraries support automatic network & transaction error recovery, automatic connection pooling, and have generally great and polished API. Not to mention they are fast.
We do have a query builder for TypeScript. But we also have codegen for every language we support: place an .edgeql file in your project and you get fully typed code out of that. That said, we will eventually have query builders for every language we support. There's only so much you can do in 3 years since we announced 1.0.
> Sorry, not convinced. We would be better off by improving on SQL itself.
Significantly improving SQL without starting from scratch isn't possible. Adding sugar - surely is possible, but we are 100% that the productivity boost we deliver with EdgeQL is worth going all in (and our users agree with us).
In any case, with Gel 6 we have full SQL support (except DDL), so it's possible to use Gel along with ORMs if that's needed. We are not SQL haters at all.
We have this blog post that was on HN front page a few times, it's a good read and explains our position: https://www.geldata.com/blog/we-can-do-better-than-sql
Earlier quoted context omitted.
Have you tried drizzle? If so, what's your beef? (The only one I've had is lack of down-migrations)
Drizzle still lacks a lot of features / stability (bug fixes required). Hopefully it improves over time.
Tight integration with the typescript tool chain has been great for us with edgeql and is about an order of magnitude less error prone than ORMs I've interacted with. Gel is a winning formula especially in the typescript world.
Tried many ORMs to get them to work in SQL, but EdgeDB's was the one that worked extremely straightforwardly, literally without any issues that weren't due to not following the instructions. No bugs, no configuration errors, no nothing. It all just worked. So I think you guys deserve more recognition and credit for what is clearly a very well-engineered product that I intend to use for some of my personal projects.
Have you tried drizzle? If so, what's your beef? (The only one I've had is lack of down-migrations)
Co-founder here - AMA.
3 questions. How does this compare to solutions like Supabase. What stands out with Supabase is the sdk support. My current project is probably going to stay on Supabase( it's a hobbyist project regardless), but hypothetically if I was an enterprise prospect how would you pitch your solution. Do you support functions, that I could call from the client for more advanced logic that can't be done with queries ? Why not…
Supabase is great and works well if you want vanilla (more or less) Postgres with some integrations ready to go.
With Gel you get a Postgres with a data layer on top. If you want to have a data model with abstract types & mixins that's easy to work with and scale in complexity, advanced access control, built-in migrations schema engine, hierarchical graph query language on top of SQL, more robust client libraries -- that's Gel.
Gel is opinionated and vertically integrated and that's it's core strength. All of its components were developed in tandem -- from the network protocol to client APIs, from the EdgeQL query language to the data model to the migrations engine and so forth. It provides more cohesive experience and can give you non-trivial performance and DX gains if you commit to it.
> but hypothetically if I was an enterprise prospect how would you pitch your solution.
Total TypeSafety enforced at all levels, built-in migrations engine, best in class access control (we'll be blogging about our access control vs RLS soon.)
> Do you support functions, that I could call from the client for more advanced logic that can't be done with queries ?
With Gel 6 we'll be announcing the new `net` module tomorrow (spoiler!). You'll be able to schedule HTTP calls from triggers/queries/functions.
> Why not brand as GelDB. Would probably be easier to Google. Plus it tells me instantly what your selling.
Well, rebranding from Gel to GelDB would be just a text change to the homepage, so hypothetically the door is open for that. But I hope we can make Gel work, just the same way it works for Render/Neon/Fly.
> PS: Can you offer something like a hobbyist tier for 10$ a month.
Stay tuned, we'll announce some news on that in a couple of days! :)