Why We Need a Standard JavaScript ORM for SQL Databases

The need for standardization is all around us, but on occasion, the JavaScript ecosystem — or rather, the tools and services built using JS — have a tendency to stray off course, which can cause disruption in the ecosystem.

In this article I’ll be discussing JavaScript clients and SDKs for SQL databases where I’ve encountered issues. I’ll ask the question: Should SaaS database providers consider dropping support of their own clients in favor of backing Drizzle ORM? As I explained in a previous post, Drizzle ORM is a modern object-relational mapping (ORM) library for JavaScript developers. It’s designed to provide a type-safe and intuitive way to interact with SQL databases, but more than that, it’s also solving what I believe to be a big problem: No two clients are the same.

JavaScript Clients and SDKs

The generally accepted solution to providing type safety for database queries in JavaScript projects is to not write raw SQL at all. Instead, we’re encouraged to use a type-safe JavaScript client or SDK.

This, at first, might appear to solve the type-safety problem — which it does. However, it doesn’t help with that pesky “no two clients are the same” problem.

Having multiple clients and SDKs in the ecosystem with their own unique syntaxes results in developers spending time learning methods specific to their chosen provider. If you’re not an “indie hacker” or a “solopreneur,” it’s quite likely you’ll be working with multiple SaaS database providers at any given time — which only exacerbates the problem.

Moreover, by using a provider’s client or SDK, many JavaScript developers won’t ever learn SQL. I think that’s not only a shame (it’s a beautiful language) but it’s also short-sighted. Your database provider of choice might not be around in the years to come, but SQL will be. This suggests a question: Why do database providers even have their own clients or SDKs?

I asked Brayden Wilmoth of Outerbase that very question. Outerbase, among other things, allows you to create, edit, visualize and explore the data in your database — all without having to write SQL. Wilmoth explained that “having providers stave off from creating their own libraries can be tricky with them wanting to make their unique value propositions easily accessible to their users [and] not having to have a dependency on an open source library being the absolute gatekeeper of them.”

And that’s a fair point: SaaS database providers want to move at their own pace, and do things in their own way. But many of these clients and SDKs are, in my opinion, not faithfully following the goals of SQL, and are potentially steering developers away from learning fundamental skills.

The Goals of SQL

I’ve mentioned these goals before in a recent article, but if you missed that one, here they are again. As outlined by Don Chamberlin (one of the principal designers of SQL), the design of the language was guided by four main goals:

1. We wanted to use the term tables instead of relations…
2. We wanted to base the language on ordinary English words like select.
3. The language should have no special symbols, and it should be easy to type on a keyboard.
4. We wanted it to have something that we called the walk up and read property. Meaning, in simple cases, a user with no special training should be able to understand a query just by reading it.

The Drizzle ORM Approach

Ideally then, what’s required is a standardized way for JavaScript developers who need type safety while writing method-based syntax, that’s not tied to a provider but faithfully follows the goals of SQL.

Wilmoth explains: “​Likely the most critically important decision an ORM library can make today is having as close of a relationship to writing (or reading like) SQL as possible. Drizzle is one of those libraries that certainly gets it right.”

Having spent some time investigating Drizzle ORM, I agree that it is very SQL-like — to the point that I don’t even think I really learned Drizzle ORM. I just wrote SQL using JavaScript method-based syntax. And I was off to the races.

However, the initial concern remains: Database providers might be subject to the decisions made by an ORM maintainer, but luckily, Drizzle ORM has thought of this already (hat tip) and is working closely with database providers to allow them to implement their specific requirements while leaving the SQL-like querying methods untouched.

“For example,” explained Andrew Sherman from the Drizzle ORM team, “@xata submitted a PR to Drizzle and added the xata driver. We reviewed it and helped a bit with the tests. The driver-specific logic is done in a way that you can replicate. Adding a driver takes a few hours, and everything else should be handled by Drizzle.”

Drizzle ORM Is Open Source and Collaborative

By welcoming database providers and allowing them to contribute to Drizzle ORM, we as developers can interact with relational databases in a standardized type-safe way, and database providers are able to implement changes that support their specific requirements.

Andrew goes on to explain that, “Yes, ‘*-core’ folders contain dialect-specific logic, which explains how the database works and what syntax and features a specific database has. Everything else consists of drivers, which explain how Drizzle should communicate with a specific database, database provider, or service.”

If you’re curious to know which providers are already adopting the “Drizzle ORM approach,” take a look at what I’m calling “the folder of dreams” on GitHub.

The providers you see here are already working with the Drizzle ORM team. Some are even going a step further and sponsoring the project, which is great news.

However, there is one provider I particularly want to mention, because, like Drizzle ORM, it demonstrates an awareness of their impact on the ecosystem and pays homage to the underlying technology.

Standing Out in a Crowded Space

I’ve long been a fan of Neon, which, for me, stands out in the crowd. They’ve never had their own client or SDK. Instead, the value proposition is simple: PostgreSQL for JavaScript developers. They have always encouraged the use of “ordinary” PostgreSQL, but have approached the client/SDK conundrum in a slightly different way.

Instead of creating their own new, fancy way to query a database, they’ve kept it old school with SQL — but what they do have is a serverless driver.

Neon’s Serverless Driver

The serverless driver is what allows JavaScript developers to query a PostgreSQL database from multiple environments, and in multiple runtimes too: Node, Deno and Bun. The serverless driver is what enables Neon to provide its own unique take on serverless databases. When using the serverless driver, you’re no longer querying a PostgreSQL database over TCP/IP; you’re querying the Neon proxy over HTTP. This in turn connects to a PostgreSQL instance (deployed to the same region as the proxy), which allows developers to use PostgreSQL in edge environments as well as “ordinary” node environments.

Naturally, Neon can also be used with Drizzle ORM. That demonstrates how a provider can move at their own pace and still offer users unique features — all without messing with the fundamental goals of the language itself.

Sadly, not every SaaS database provider operates in this way.

A Pattern Is Emerging

So it seems that SaaS database providers are already converging on a common standard, which can only be a good thing.

In my view, SaaS database providers shouldn’t have their own clients or SDKs and shouldn’t be leading developers down the wrong path. I am a proponent of developer education. If you’re working with databases, you should (at the very least) have a basic understanding of SQL. Once you do, I think you’ll take to Drizzle ORM like a duck to water.

Even if you don’t agree with my take, give the repo a star on GitHub — and if you’ve got a bit of VC money to throw around, Drizzle ORM is a deserving project.

Paul is a Senior Software Engineer, Independent Developer Advocate and Technical Writer. More from Paul can be found on his site, paulie.dev.

Read more from Paul Scanlon