As applications become increasingly data-driven, the challenge of managing database access securely while maintaining developer productivity has never been more critical.
In this exclusive VMblog Q&A, Bryan Clark, VP of Product at Neon, discusses a significant move that could reshape how engineering teams handle database security – the general availability of Neon Authorize. This new offering aims to simplify one of Postgres’s most powerful yet underutilized features – Row-Level Security (RLS) – by making it more accessible and production-ready for modern development teams.
The announcement comes at a time when database security is top of mind for organizations, yet many struggle with the complexity of implementing granular access controls at the database layer. Through a partnership with Drizzle, Neon’s approach could bridge the gap between robust security requirements and developer experience, particularly for teams building on PostgreSQL.
VMblog: For readers who may not be familiar with Neon’s offering, can you give the quick elevator pitch?
Bryan Clark: Neon is an open-source Postgres Database platform. By separating compute and storage, Neon can offer fully-managed serverless databases. They scale automatically based on load, and branch instantly for dev and test databases. These unique features help thousands of engineering teams ship reliable and scalable applications faster.
VMblog: Today it was announced that Neon Authorize is generally available, which is a way that companies can manage permissions and access controls at the database layer. Is this the first time this is possible and can you explain the main benefits?
Clark: Postgres introduced Row-Level Security (RLS) in version 9.5 in 2016. While some providers have used RLS, it’s often complex, developer-restrictive, or not suited for production. We partnered with Drizzle to simplify RLS with an easy API, integrate multiple providers, and keep everything in code, making it production-ready.
RLS syntax can be challenging. Although it’s declarative, managing complex authorization rules becomes cumbersome. With Drizzle (and collaboration with Prisma), we developed a straightforward syntax for managing RLS rules.
To avoid provider lock-in, we integrated with various authentication providers, giving developers the freedom to choose and switch as needed. More options mean better solutions.
RLS rules are stored in the database, but their definitions should live in a developer’s code repository. With our system, developers build RLS rules locally using Drizzle, push changes to a preview environment for testing, and only then deploy to production-ensuring safe, controlled updates.
VMblog: What are the disadvantages of this approach? Anything that security teams would be concerned about?
Clark: Security teams should be on the lookout for very complex RLS rules, proper migration of rules, and testing of authorization systems. As the number of rules and rule complexity increases, the syntax of RLS makes it harder and harder to reason about. Keep in mind that change RLS rules is a database migration, old rules must be dropped and new rules created, but if a migration were to drop a rule and not recreate it you are without Authorization in your stack. And finally there isn’t good testing infrastructure for RLS rules, we recommend using an integration test approach to ensure your rules are functioning properly.
VMblog: Does this replace the need for traditional authorization tools? Or are you integrating with existing tools to unlock this new ability for users?
Clark: RLS should enhance traditional authorization tools. At Neon we believe RLS is a good extension to your application’s rules. Similar to other database tools like Foreign Keys, Unique Constraints, or Cascade Deletes, the database assists developers in building better systems.
Foreign Keys, for example, help developers ensure consistent rules across different tables. If you’re creating a new row in the comments table, that row should correspond to a user in the users table. A developer’s application is responsible for ensuring this consistency, but using the database to help is key to building a more robust and sustainable system.
Using RLS rules to ensure that an authenticated user is only authorized to access the rows in a table they own is an excellent way to bring additional security to the database level.
##
