3 ms·
It's built on Postgres, but it isn't a _thin_ wrapper. We lean hard into Postgres query machinery and type system in order to pull off EdgeQL and graph-relatio
by RedCrowbar 5y ago
It's built on Postgres, but it isn't a _thin_ wrapper. We lean hard into Postgres query machinery and type system in order to pull off EdgeQL and graph-relational efficiently.
- samhw 5y agoAh, OK, interesting! I don't have an immediate use case personally, but I wish you guys the very best. Honestly, database space needs way more competition than it has at present. There are countless permutations of the choices that database designers face, so it's a shame there aren't mature products for more of them. I hope this particular permutation turns out to be a good one for lots of people :)
- RedCrowbar 5y agoThank you!
- samhw 5y agoargh - the database space*
- Aeolun 5y agoDoes this mean that at the end it submits SQL queries to postgres? Or is the integration deeper?
- RedCrowbar 5y agoWe compile EdgeQL queries into SQL currently, because it makes the architecture simpler and less us run on unmodifed Postgres, but conceptually nothing stops us from targeting the query planner directly via an extension or an alternative frontend that consumes EdgeQL IR direclty.
- samhw 5y agoAh, this is interesting: so Postgres is effectively a 'backend' for you, in much the same way that e.g. InnoDB is a backend for MySQL[0]? And you - or hypothetically the end user - could change the backend, e.g. to Cockroach for better horizontal scalability, while trusting that EdgeDB will only rely on Postgres's public API at least in meeting its own public API/contract? [0] It's hard to make that analogy with Postgres b/c it only has one storage engine, but of course the separation still exists.
- RedCrowbar 5y agoThat’s exactly right.