I really like the re-imagination of the type system, data model, and the user interface. This is an area where databases could be significantly better than they currently are.
My only concern is that there is nothing about the backend that suggests that this will be scalable beyond tiny data sets. Even on single machines, there is a performance cliff that arrives very quickly when doing these kinds of data model traversals unless you are using something exotic under the hood.
> I really like the re-imagination of the type system, data model, and the user interface. This is an area where databases could be significantly better than they currently are.
Thank you!
> Even on single machines, there is a performance cliff that arrives very quickly when doing these kinds of data model traversals unless you are using something exotic under the hood.
PostgreSQL is used under the hood. We compile EdgeQL to an efficient SQL behind the scenes, similarly to how you compile a high-level language to lower-level language. All our fancy data types fully utilize the relational model, so what's achievable with scaling Postgres will be achievable with EdgeDB. I know quite a few massive deployments of Postgres that work just fine, there's simply no reason why EdgeDB would be different.
> May I assume that the slight modifications you were required to make to postgres in order to support your features weren't just bug-fixes?
Yes. Some of them, like strict parsing of timezone-aware vs naïve datetimes can be upstreamed (as a configurable option) if the Postgres community accepts it. It's in our interest to upstream things like that :) We'll see how it goes.
My only concern is that there is nothing about the backend that suggests that this will be scalable beyond tiny data sets. Even on single machines, there is a performance cliff that arrives very quickly when doing these kinds of data model traversals unless you are using something exotic under the hood.