I was wondering the same thing. Why not rather than build a new database engine, write a library like an ORM that transpiles a language - like EdgeQL - to SQL, so you can attempt to use it, without switching underlying database engine, and still use your old SQL code?

EdgeDB is built on Postgres, it's not from scratch.

My Mac app, Strukt, does a bit of this. The main problem is that the basics of the various databases don't align very well. The functionality that's common to all databases is quite weak. Even such things as case sensitivity are drastically different. And for many of the differences, there's simply no way to emulate the other's functionality, correctly and efficiently.

C compiles to assembly or machine code, and TypeScript compiles to JavaScript, and in both cases you have the full power of the level you're targeting, so it's fine. An RDBMS has very specific fast-paths that you really need to hit, or the whole exercise becomes pointless. It's like trying to write a 3D game in JavaScript without any way to access the GPU or even SIMD ops. We can do 3D games in JS today, but that's really only feasible because the browser vendors went and exposed the basic fast paths.

Yeah then we get the best of both worlds. I might use that if it existed. All else being equal, EdgeQL the language looks great compared to SQL.

Isn't this what an ORM is? Or at least an ORM covers some new features that users can opt-in to without losing the ability to write raw SQL. I guess it's not the perfect analogy to TypeScript, but I think it's a pretty good comparison. The other thing I can think of are things like GraphQL which can be used as an abstraction on top of a SQL DB.

Some ORMs like Hibernate have their own QL, but they typically preserve the SQL data model.

This isn't just replacing SQL, they're trying to implement a new data model that is backed by Postgres.