What if your API is just a database connection?

Every data product ends up building the same layer on top of a database - REST or GraphQL APIs, authentication, pagination, filtering, sorting, and permissions all become part of the application, even though many clients already know how to talk to databases directly.

This talk presents the design of a PostgreSQL wire protocol gateway that explores a different approach. Instead of exposing another API, the gateway exposes a PostgreSQL endpoint while enforcing permissions before queries ever reach the database.

The gateway behaves like a normal Postgres server, so existing clients such as BI tools, notebooks, and AI agents can connect without custom sdk or client changes.

The talk covers how the gateway parses SQL into a PostgreSQL AST, validates and rewrites queries before execution, enforces row and column-level permissions, filters schema introspection, and blocks unsafe statements.

I'll also cover the limitations of this approach, where query rewriting falls short, and why PostgreSQL's own permission model is still needed as a second layer of defense.

I will show a live demonstration showing query rewriting, multiple users executing the same SQL while receiving different results, pg catalog filtering, and existing PostgreSQL clients connecting without any modifications.

• Why exposing PostgreSQL directly is worth considering for some applications.

• Parsing and rewriting SQL instead of building another API layer.

• Building permission checks into a SQL gateway.

• Making existing PostgreSQL tools work without custom SDKs.

• Lessons learned, trade-offs, and where this approach breaks down.