From what I'm seeing, the upgrade path is essentially dump and restore. This was the case for moving from EdgeDB v1 to v2 as well. Since EdgeDB is a fast moving target this creates a lot of friction for older databases to upgrade.
Is there plans for replication support or a more robust upgrade path?
I find the support of plain SQL over the Postgres wire protocol (intended for BI usecases) really interesting.
The article mentions a "SQL-to-SQL" compiler -- how exactly does this work?
Are you intercepting plain SQL queries over the wire, analyzing them, and then rewriting them into the form of queries that EdgeDB internally generates?
I am using Prisma in the production. I want to ask:
- Can EdgeDB solve the problems like `soft-delete`? Prisma can't do this good, there are third-party packages, but I don't trust these packages because authors often drop support.
- How about hooks, for example, I want to trigger scripts after/before a record is added to the table.
No, we think we should have it eventually but haven't started to work on it yet. Potentially we can create a C-wrapper for the Rust lib, which isn't ideal but might be doable in a shorter time frame.
> Will EdgeDB Cloud be fully replicated similar to https://neon.tech?
Eventually yes. Our client libraries APIs are designed in such a way that it's easy for us to automatically route read queries to the nearest replicas and do other magic.
> I want to use EdgeDB Cloud but I want the latency to be that of Grafbase for example.
We'll be working on lowering the latency as much as we can. But you also have to keep in mind another aspect - which is the composability of EdgeQL, which allows you to pipeline multiple operations in one query. That query will get you all of your data in one round trip, something that doesn't typically happen with ORM libraries and SQL in general.
Analytic queries are not the primary intended use of EdgeQL. It would be doable, since EgdeQL is compiled SQL within the edgedb server, but this compilation depends on the schema of the database - quite heavily actually. It expects specific table and column names, so it would not work for an arbitrary database that you have.
It would be possible however, to take an empty postgres instance, hook edgedb server to it, apply your schema and insert all the data.
> Analytic queries are not the primary intended use of EdgeQL
You can write analytic queries with EdgeQL now, albeit we do need to add support of windowing. While we certainly prioritize usefulness of EdgeQL for the kind of efficient data fetch operations you need when you build apps and services, the language itself was designed with a goal of becoming equally good for analytics too. We'll get there.
It's a reality, Posgres' analyze output wasn't designed for the plans that EdgeQL commands can have, given the composable nature of our language. You can just do much more in one op and that balloons the plan. Not in a bad way, but you have to know how to read those things to make good understanding of it. Our goal is to streamline this for EdgeQL as much as we can.
Last time I looked at EdgeDB, it needed a separate process/server from the Postgres database. Has that changed since then? Would it be possible to turn EdgeDB into an extension of sorts rather than running it in a separate process?
EdgeDB is designed on the assumption that it fully controls and manages the underlying Postgres instance. This is why we can have a better/faster binary protocol, proper connection pooling on both client and server, and many many other perks. Making it an extension would drastically limit what you can do with it, and besides, it will take years to make this extension available on AWS and others anyways. All in all, it's not worth it, even though on a surface it sounds like a good idea.
I found the developer experience of EdgeDB to be really great. A CLI tool that does all the work, a very declarative schema language that is easy to learn, migrations built in. Helpful error messages
The dotnet and TypeScript libraries were great as well.
All around a fun DB to use, and it builds on PostgreSQL instead of reinventing the wheel.
It's really hard to get people to not-use SQL and one should always look what tool is right for the problem. But I hope a lot of more tools/libraries aim for this kind of enjoyable experience.
Might be time to update the roadmap here.
Good to see triggers. I need window queries and subscriptions and then it might become my goto DB for small projects.
I was enthusiastic about the name and it looks neat, but it doesn't seem like it's made to compete with SQLite for use cases on the "edge" of the network.
39 comments
[ 4.1 ms ] story [ 81.5 ms ] threadFrom what I'm seeing, the upgrade path is essentially dump and restore. This was the case for moving from EdgeDB v1 to v2 as well. Since EdgeDB is a fast moving target this creates a lot of friction for older databases to upgrade.
Is there plans for replication support or a more robust upgrade path?
The article mentions a "SQL-to-SQL" compiler -- how exactly does this work?
Are you intercepting plain SQL queries over the wire, analyzing them, and then rewriting them into the form of queries that EdgeDB internally generates?
Any chance you'd be able to link the relevant parts of the code?
I had a look through the "/pg" directory but there was a lot there and it wasn't immediately clear which parts did what
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...
- Can EdgeDB solve the problems like `soft-delete`? Prisma can't do this good, there are third-party packages, but I don't trust these packages because authors often drop support.
- How about hooks, for example, I want to trigger scripts after/before a record is added to the table.
Yes, with access policy rules. E.g
The above will effectively "hide" objects with `.deleted` set to `true` from all queries when the `hide_deleted` global is set to true.> How about hooks, for example, I want to trigger scripts after/before a record is added to the table.
EdgeDB supports triggers: https://www.edgedb.com/docs/changelog/3_x#triggers. Future versions will add support for causing effects outside of the database, e.g. call a WebHook or some such.
Couldn't find anything on the website but assumed it would be underpinning e.g. the Python lib.
I want to use EdgeDB Cloud but I want the latency to be that of Grafbase for example.
benchmark here: https://edge-data-latency.vercel.app
I know EdgeDB exposes GraphQL as part of plugin. I assume EdgeDB Cloud lets you setup production GraphQL setup without any effort?
3.0 looks very exciting, well done.
Eventually yes. Our client libraries APIs are designed in such a way that it's easy for us to automatically route read queries to the nearest replicas and do other magic.
> I want to use EdgeDB Cloud but I want the latency to be that of Grafbase for example.
We'll be working on lowering the latency as much as we can. But you also have to keep in mind another aspect - which is the composability of EdgeQL, which allows you to pipeline multiple operations in one query. That query will get you all of your data in one round trip, something that doesn't typically happen with ORM libraries and SQL in general.
> 3.0 looks very exciting, well done.
Thank you!
Is there a way to write EdgeQL and generate the corresponding SQL? That would be so much better!
It would be possible however, to take an empty postgres instance, hook edgedb server to it, apply your schema and insert all the data.
You can write analytic queries with EdgeQL now, albeit we do need to add support of windowing. While we certainly prioritize usefulness of EdgeQL for the kind of efficient data fetch operations you need when you build apps and services, the language itself was designed with a goal of becoming equally good for analytics too. We'll get there.
Is it sort of sarcasm or it's cruel new reality, Team behind EdgeDB observes?
The dotnet and TypeScript libraries were great as well. All around a fun DB to use, and it builds on PostgreSQL instead of reinventing the wheel.
It's really hard to get people to not-use SQL and one should always look what tool is right for the problem. But I hope a lot of more tools/libraries aim for this kind of enjoyable experience.
We'll get there.