First-class support for Postgres

[mattvr]

Deno still doesn't have a good native Postgres solution, despite Postgres being used in many projects and examples, and is on track to become the #1 DBMS.

The ideal outcome is there's a recommended/blessed postgres package for use with Deno Typescript projects in 2025 and beyond. (If there is one please let me know).

The current solutions have been plagued with subtle issues related to TLS, random disconnects, and Deno compatibility over the years continuing to now:

1. jsr:@db/postgres aka denodrivers/postgres

Generally billed as the Deno-first postgres solution, but is relatively immature & unmaintained and suffers from many connection and functionality issues:

• TLS caCertificates not working denodrivers/postgres#506
• ConnectionError: The session was terminated unexpectedly  denodrivers/postgres#483
• BrokenPipe: Broken pipe (os error 32) not handled in reconnect logic denodrivers/postgres#436

As these issues are critical and ongoing (connections can't be made securely or break randomly), and are without active development, this project hasn't really been suitable for production use or even hobby projects in my experience.

2. npm:postgres aka Postgres.js

This is a popular modern TypeScript postgres client, and states it supports Deno.

In practice, there's Deno-specific connection reliability issues with this library as well, see:

• Issue connecting in Deno via SSL porsager/postgres#1083
• Connection pool sometimes does not end properly porsager/postgres#861

I personally find this API to be a bit opinionated with use of template literals, making it not easily adaptable to existing SQL code. Thus it may not be the best default option for Deno examples and projects.

Last, Postgres.js could be added to jsr which has not been done yet.

• Not available on jsr.io porsager/postgres#839

3. npm:pg aka node-postgres

This is the most popular overall JS postgres client. From my experience, it's the best and most reliable solution, but it's far from ideal.

The main downsides are:

1. It does not have TypeScript types or JSDocs for any of its code, making it difficult to use, and is written in an older CJS style.
2. Its performance is relatively slow compared to others.
3. Its Deno support is still not fully resolved, and still may hit node-compat issues with its libpq version.

• Discussion: Deno Port brianc/node-postgres#2225

---

Overall, I believe it would be beneficial for the Deno core team (and/or community) to push for a reliable and consistent approach to using Postgres or SQL, prioritizing making database connections stable and secure.

Postgres is at the heart of the majority of web apps today, and is now natively integrated with Deno Deploy, yet the reality is there isn't a modern & reliable Postgres solution for use with Deno yet.

[Hajime-san]

I think that it is not a good idea to add clients for third-party services or software to a language runtime's built-in API.
(Secretly, the same goes for the Deno.Kv API.)
Users lose control over the version of the backend.
And you will have to wait for the language runtime to fix it if a vulnerability is found in the implementation.

In this regard, I don't think node:sqlite or C# System.Data.SQLite is a good idea either.
It is a good design for web frameworks to transparently support ORMs for DBMSs like PostgreSQL or MySQL, for example, Ruby on Rails' Active Record.
However, it would suddenly seem strange if Ruby supported the PostgreSQL client API.
IMO, the best thing would be to improve development support and compatibility for third-party libraries.

FYI, an issue seemed to be fixed recently that is related to npm:postgres.

• npm:postgres errors with CONNECT_TIMEOUT when using SSL #28526