Build multi-tenant RAG with Neon's database-per-user model — no nosy neighbors, max isolation, minimal costs
Docs/Neon Authorize/What's next

The future for Neon Authorize

Our vision for what comes next

Neon Authorize is an exciting feature, and we want to build more capabilities on top of it.

Here are some ideas of things we could build next — in no particular order (unless stated otherwise). If you see something you like, or something you'd like to see but don't, let us know in Discord!

Accepting JWTs for TCP and WebSocket connections

We want Neon Authorize to work over any type of connection: TCP, HTTP, or WebSockets. This is probably our highest priority. Accepting JWTs over TCP (in the password field for the Postgres role) would mean that any Postgres SDK in any programming language could support Neon Authorize.

Local development experience

We'd like to offer a very easy experience for developers to use Neon Authorize in their local machines without an Internet connection.

Custom roles

We aim to introduce custom roles for Neon Authorize, in addition to the "authenticated" and "anonymous" roles we have now. We're also exploring the idea of adding "Neon-managed" roles, which would be managed by our platform and included by default in every branch and read replica.

Automatic installation of pg_session_jwt and set up of role grants

The pg_session_jwt extension is required for Neon Authorize to work. We're exploring the idea of automatically installing the extension and setting up the role grants for the authenticated and anonymous roles.

JWT audience checks

The aud field in a JWT typically defines the token's intended recipients. In the future, we want to allow users to customize the expected aud field in the JWTs they use with Neon Authorize, providing greater flexibility and control.

Multi-tenancy through Neon Authorize

We've discussed supporting multi-tenancy via Neon Authorize, allowing users to configure how their JWTs should trigger Neon to route database requests to different Neon instances.

Neon CLI for configuration

We would like to add support for configuring Neon Authorize from the Neon CLI.

Neon Authorize for Neon Console frontend database requests

Using Neon Authorize for database requests from the Neon SQL Editor can help map the Neon Console user to the individual who issued the request.

Proxy rate limiting

Implementing proxy rate limiting will make SQL from the client safer.

Query allow-listing

The ability to define a query allow-list would help increase the safety of SQL queries from the client.

Investigate React/TanStack query hooks for SQL queries

We're exploring the generation of React Query hooks for SQL queries, simplifying the process of building applications that leverage SQL from the frontend, or that use React Server Components.

Simplified OAuth flow for JWKS endpoint

Instead of manually copying and pasting the JWKS endpoint from your authentication provider's console, we are interested in developing an OAuth flow that allows you to simply Sign in with <Provider>, automatically populating the JWKS endpoint.

User interface for RLS and user impersonation

We'd like to add a user-friendly UI for managing RLS policies with AI assistance and a way to simulate SQL queries from different application users and JWT properties.

Last updated on

Was this page helpful?