Feature Request: Add Support for Bun SQL Driver in PostGraphile

[zuohuadong]

Feature description

Add support for Bun's native SQL driver (Bun.SQL) in PostGraphile. This would allow PostGraphile to leverage Bun's high-performance database connectivity when running in the Bun runtime environment.

Bun.SQL is a unified SQL API introduced in Bun 1.2+ that provides native database connectivity for PostgreSQL, MySQL, and SQLite with significantly better performance than traditional Node.js database drivers.

Key aspects of this feature:

• Integration of Bun.SQL as an alternative database driver option in PostGraphile
• Support for PostgreSQL through Bun's native implementation
• Leverage Bun's performance advantages for database operations
• Maintain compatibility with existing PostGraphile features while using the Bun driver

Motivating example

Performance Benefits:
According to Bun's benchmarks, Bun.SQL demonstrates substantial performance improvements:

• Up to 6x faster than Node.js postgres package for high-concurrency workloads
• Lower latency and higher throughput in database operations
• More efficient memory usage compared to traditional drivers

Development Experience:

• Unified development stack when using Bun as the runtime
• Simplified dependency management by using Bun's built-in capabilities
• Better integration with Bun's tooling ecosystem

Use Cases:

1. High-performance applications that require maximum database throughput
2. Bun-based projects seeking to leverage native capabilities
3. New greenfield projects using modern JavaScript runtimes

Breaking changes

This feature should not introduce breaking changes to existing PostGraphile installations. It would be implemented as:

• An optional driver that only activates when explicitly configured
• Additional configuration option for the database connection
• Fallback to existing drivers when not using Bun runtime

Potential considerations:

• Feature parity verification between Bun.SQL and existing PostgreSQL drivers
• Testing across different Bun versions to ensure compatibility
• Handling of Bun-specific connection parameters and configuration

https://bun.com/docs/runtime/sql

Supporting development

I [tick all that apply]:

• am interested in building this feature myself
• am interested in collaborating on building this feature
• am willing to help testing this feature before it's released
• am willing to write a test-driven test suite for this feature (before it exists)
• am a Graphile sponsor ❤️
• have an active support or consultancy contract with Graphile

[benjie]

Please do not submit AI-generated issues; if you're tempted to do so, please instead submit the prompt that you would issue to the AI and allow me to run it through AI myself should I so choose.

PostGraphile’s data access goes through adap­tors in Grafast’s @dataplan/pg layer, so the right way to experiment with Bun.SQL is to implement a new adaptor that conforms to the same interface as grafast/dataplan-pg/src/adaptors/pg.ts (there are core classes you can extend from). You can build that adaptor completely outside the PostGraphile repository: just use your adaptor instead of postgraphile/adaptors/pg.

If you do get a Bun-backed adaptor working, we’d love to review it as a pull request to the repo so others can benefit. Feel free to share early progress and seek further input.

[benjie]

I'm assuming the prompt was something along the lines of "Please fill out this issue template requesting support for Bun.SQL and make a compelling argument for its usage". Please correct me if I'm wrong.

[zuohuadong]

@benjie Sorry, it's my mistake.There are no LISTEN/NOTIFY-related APIs in Bun SQL's type definitions.Bun SQL also does not expose PostgreSQL's NOTICE messages.

[benjie]

That's okay; those features are optional. Notice can be skipped over (just return empty array). Lack of listen/notify means that users will not be able to use Postgres pub/sub for subscriptions, but that's also fine.

[benjie]

I'm not entirely sure how to handle the lack of listen/notify; but the simplest method is probably just to return a rejected async iterator any time the person tries to subscribe.

async function *nope() {
  throw new Error(`The Bun.SQL adaptor doesn't support LISTEN/NOTIFY at this time.`);
}

[zuohuadong]

@benjie Thank you very much for your reply. My idea is to temporarily solve this through adapter polling and then switch to the native solution once bun sql supports LISTEN/NOTIFY. I used AI to generate a demo, which I will share later. Thanks again.

[zuohuadong]

@benjie see: https://github.com/zuohuadong/grafast-adapter-bunsql

[benjie]

If that serves your needs, great. But I would not encourage that approach to working around a lack of LISTEN/NOTIFY - just don't use LISTEN NOTIFY if you don't support them.

[zuohuadong]

@benjie Thanks! I’ve switched it to experimental support – you’ll need to turn it on manually.
https://github.com/zuohuadong/grafast-adapter-bunsql