Was the rebrand really just for simplicity and clarity? It seems like a lot of work to change the name when it was already a pretty established toolchain, not just for your team, but, and this is more important, for your community.
I actually think EdgeDB was a far better name. It actually meant something; yes, it wasn't a pure graph database, but it did work with the general concept of graphs and edges. Gel means nothing. Even the domain name: geldata.com makes no sense. You're not selling or creating data, it's a database system/layer.
I've been a true evangelist for EdgeDB over the last two years, but this has really irked me - irrationally so, I'm aware(!), but I just can't see the benefits outweighing the drawbacks here. It feels like it has to have been a result of some legal action or something.
And just as LLMs were starting to catch up with their knowledge cutoff to include EdgeDB too! Now it'll be another two years until they know what you're talking about again. I know, first world problems.
Is the query language name changing, by the way? Or is that still EdgeQL? Please let sanity prevail over at least one thing and don't call it "jel-q-ell"!
As someone who has used EdgeDB religiously for years now and still has projects with EdgeQL code generators (that use old syntax), one of my earlier requests was, "Please don't break things". Don't change the syntax of EdgeQL in a backward incompatible way, don't rename commands in the command line, etc. It's really not a big issue to remember some not-so-perfect term. Requiring thousands of people to unlearn/relearn new terms, commands, and names, and rewrite scripts and documents - is an issue. Didn't expect to see the whole name EdgeDB being replaced with another, ungoogleable name.
The argument of "some developers don't look past name and think that it's an edge-computing database" is superficial at best. I can get how it can be annoying, personally, but unless it was backed up with data showing that it hurts adoption, I wouldn't take it as a serious problem worth forcing thousands of users to switch to a new name/commands.
Following this logic, these developers could also ask "MySQL? Huh, you must be running it only on your own servers" or "Gel? Huh, is it some toy database for kids?".
I wish more people realized the enormous cognitive costs and debt created by such renamings. :/
Sorry, divan, for causing pain. This wasn't an easy decision. FWIW we're still strict about backwards compat and all you stuff should continue working.
Scott from Gel here. I suspect for everyone we talked to in the "So, this is a database for Edge computing?" camp there were a dozen people who thought that and just kept moving even if they were our target audience. It's hard to quantify just what the cost have having a name with such a strong connotation (which has arguably gone up and down in the hype cycle over the lifetime of EdgeDB) has been.
Gel doesn't have any really strong existing computing connotations, so maybe people might make a stretch that it's about some non-computing-related domain and maybe we miss reaching them. But that just seems far less likely than trying to continue to push against the overwhelming feeling that "Edge" just has too much baggage and was working against us.
Personally, I think it's fine if people find the name confounding or just personally dislike it. I think products like Supabase, Neon, Drizzle, CockroachDB, Django, Flask, Express, etc etc kind of prove that if your name is general enough, you'll overcome that reaction eventually via recognition for the value of the product itself.
For every person who passed on EdgeDB on the suspicion it was related to edge computing, someone may have clicked it for the same reason entirely and found something else compelling.
Personally I think EdgeDB was a much better and descriptive name than Gel. I haven't used EdgeDB/Gel yet, but have been looking at it with excitement for years now waiting for the opportunity to use it.
I am worried that the rename will work against you since you've built such an excellent brand around EdgeDB with so many glowing testimonials.
That's fair, but I think going on _just_ the quantifiable stuff was still enough of a justification for us. My feels are that the cost of our confusing former name is higher than we know, but the known cost was still great enough.
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 brand as GelDB. Would probably be easier to Google. Plus it tells me instantly what your selling.
PS: Can you offer something like a hobbyist tier for 10$ a month. I don't want to deal with my project randomly shutting off, but I have extremely low requirements in terms of storage during development.
> How does this compare to solutions like Supabase.
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! :)
I don't know about migrating my current project, but I'll definitely try Gel for a future project.
>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.)
Very very cool.
If I just dump my Supabase project's Postgres DB can I load the SQL into Gel and have everything work. Or would I need to setup the schema.
Ultimately I'm just looking for an open source alternative to firebase-> while amazing, I can't exactly claim to have an open source project that requires a closed source service.
Last question, Supabase heavily pushes the use of Captchas if you use any anonymous authentication. Does Gel also suggest this. Notably Firebase doesn't care, which makes it much easier on end users.
Imagine having to solve a captcha to browse Amazon and add products to your cart, you'd probably just use something else.
Ok, just one more question! How is your SDK support. JavaScript is a given, but Godot support would be nice.
> If I just dump my Supabase project's Postgres DB can I load the SQL into Gel and have everything work. Or would I need to setup the schema.
Currently you have to define your schema in Gel [1] and then write scripts to port your Postgres data into Gel. It's cumbersome, we know, we'll be working on improving the migration flow.
> Last question, Supabase heavily pushes the use of Captchas if you use any anonymous authentication. Does Gel also suggest this. Notably Firebase doesn't care, which makes it much easier on end users.
We don't have captchas implemented, but when we do, it will be an opt-in configuration option.
> Ok, just one more question! How is your SDK support. JavaScript is a given, but Godot support would be nice.
Thanks for responding! I'm about 60% done with my current project so I don't think I'll be up to migrate( again, originally I started with Firebase), but I still definitely consider Gel for future projects.
Or if I ever interview with your team( hiring? ) I'll migrate my existing project and document the process.
EdgeDB has declarative schemas with baked in migrations and is a clear differentiator.
Supports namespaces within a database.
EdgeQL improves nested query performance as they are compiled into a single postgres query
How to deal with eventual slow queries? I currently have a system with complex queries with a lot of joins where I had to create a custom materialized table
These queries also deal with permissions & realtime scheduling so endpoint caching doesn't solve it
Have gel users hit any performance issues, and how have they dealt with them?
We're shipping a slow query log UI in this version to continuously monitor queries in your system.
Our users do get performance issues, usually because they start really using our data model to its full potential, creating tens / hundreds complex access policies, 100-lines long EdgeQL queries etc. We have EXPLAIN command to deal with, and we also support our customers directly helping them understand and fix their system. All of the findings trickle down to the core product so that the rest can benefit too.
It says gel is to Postgres what typescript is to JavaScript, so can I add gel to an existing Postgres instance and get the benefits of the nicer query language or does it rely on special tables? If I use some other extension like timescale is that compatible with gel?
And is there a story for replication/subscribing to queries for real time updates?
Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres
> If I use some other extension like timescale is that compatible with gel [...] Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres
Playing nice with the ecosystem is the goal. We started off with more of a walled garden, but with 6.0 a lot of those walls came down with direct SQL support and support for standalone extensions [1]. There is a blog post coming about this specifically tomorrow (I think).
> And is there a story for replication
Replication/failover works out of the box.
> subscribing to queries for real time updates?
Working on it.
> so can I add gel to an existing Postgres instance and get the benefits of the nicer query language or does it rely on special tables?
Gel is built around its schema, so you will need to import your SQL schema. After that you can query things with EdgeQL (or SQL/ORM as before).
In the just released new version we've added SQL support, so now you can use SQL taking full advantage of our data model (access policies, mixins, etc) and the network protocol (automatic recovery on network & transaction error, automatic connection pooling on client/sever).
We'll continue bridging the gap to make it easier for companies to adopt Gel for an existing database. We either will invest in creating a tool for migration, or maybe some more exciting options we're currently pondering on.
Gel is somewhat similar to Supabase on the surface—both run on Postgres, both have Auth, and both offer AI features, a CLI, and a UI, among other similarities.
However, there’s a big difference beneath the surface: Gel comes with a high-level data model (abstract types, mixins, access policies) that replaces tables and joins. It’s still relational (and we’re about to publish a paper on that), but it’s more high level, strict, and yet more flexible.
On top of that, we have a built-in migration system (where schema is a first-class citizen), a performance-tuned network protocol, and a query language called EdgeQL, which is like a child of SQL and GraphQL. These are just a few of our “deep” features.
All in all, Gel is a fresh take on day-to-day database development. We cut no corners in trying to push the core database developer experience forward.
Just a user here, but I'd say there are many reasons, one of those reasons is in your name: auth.
GelDB's auth is versatile and doesn't cost a dime, while Supabase auth is only free up until 50,000 monthly active users, then it costs $0.00325 per MAU (> 100k MAU).
I personally just love its query language and the typescript query builder.
Yeah, we'll be repairing this shortly. FWIW we're completely revamping our documentation, it's almost a full rewrite, focused on bringing clarity and logic to the navigation, improving search, etc. We should fully wrap it up in a week or two.
I was hoping to learn more but many of the docs.geldata.com links on the GitHub page are 404 right now, mentioning just in case nobody has reported that yet.
> If I have an existing postgres db how hard is it to migrate?
The main hurdle would to migrate the schema. You'll have to define your schema in Gel (take a look at the reference here [1]) and write a script to copy your data.
We are discussing internally how we can simplify this process, this is becoming a popular question.
> Can I write regular joins if I need to?
You can use EdgeQL and SQL side by side now though one connection in the same function. Gel's schema is still relational (even though it's more powerful with features like multiple inheritance).
This page describes the details [2] of how SQL works with our schema (spoiler: it's very straightforward and no different from a hardcoded SQL schema).
> Do you have plans or do you already support db branching ?
We call Postgres databases "branches" in Gel. And we have tooling around them [3] to have git-like experience with them. Conceptually you can map (manually) your Gel branches to your Git branches if you wish.
