November 2024 Summaries

JSON Web Tokens (JWTs) are standardized, compact, self-contained tokens for transmitting information securely between two parties. They emerged in the early 2010s as a more efficient and stateless alternative to traditional session-based authentication. JWTs consist of three base64-encoded segments: header, payload, and signature. The payload contains the actual data being transmitted, while the signature ensures the token's authenticity. JSON Web Key Sets (JWKS) provide a standardized way for services to share public keys used for verifying JWTs. In Neon Authorize, JWT claims are used to enforce row-level security policies in Postgres databases, ensuring users can only access data they are authorized to see.

JSON Web Tokens (JWTs) have become a foundational element in modern web authentication and authorization, offering a stateless, compact, and self-contained way to transmit information securely between parties. Emerging in the early 2010s, JWTs addressed the scalability and cross-domain limitations of traditional session-based authentication, becoming standardized in 2015 as RFC 7519. JWTs consist of three base64-encoded parts: the header, which includes metadata about the token; the payload, which contains claims about the user and session; and the signature, which ensures the token's authenticity. These tokens are particularly beneficial in microservices architectures to verify user identity without relying on a shared session database. JWTs are signed but not encrypted by default, providing authenticity and integrity but not confidentiality. They integrate smoothly with platforms like Neon RLS, which uses JWT claims to enforce row-level security policies, ensuring users access only their authorized data. For secure verification, JWTs rely on JSON Web Key Sets (JWKS) to manage cryptographic keys, allowing for key rotation and trust verification. Although they are not encrypted, JWTs can be used securely by storing non-sensitive identifiers within the token and accessing sensitive data through the database when needed.

Neon has launched a new tool called Schema Diff GitHub Action, which simplifies schema migrations by automatically tracking changes as comments on pull requests. The tool is designed to work with Neon branches, allowing developers to create isolated environments for testing schema changes safely before applying them to the main branch. By automating schema comparisons and posting updates in a single comment, this tool aims to reduce manual work, enhance review processes, and improve overall efficiency in managing schema migrations.

Neon has introduced the Schema Diff GitHub Action, a tool designed to streamline the process of schema migrations by automatically tracking and commenting on schema changes within pull requests. This action, which integrates with Neon branches, allows developers to test schema changes in isolated environments before implementing them in the main branch. By utilizing Neon’s ability to create child branches with exact copies of data and schema, developers can safely compare schema differences between branches. The Schema Diff tool, initially available via the Neon Console or CLI, has now been enhanced to function as a GitHub Action, automatically updating pull requests with schema change comments, thus saving time, reducing errors, and enhancing collaboration by keeping all team members informed of changes without needing to manually inspect SQL files. This tool supports a more efficient and developer-friendly workflow by automating tedious tasks and is available for all Neon users, including those on the free plan, with detailed setup instructions provided in the documentation.

Neon has launched its Bug Bounty Program in partnership with HackerOne to enhance security and maintain user trust. The program engages talented security researchers and ethical hackers worldwide, allowing them to test specific high-impact areas of the platform. Participants will be rewarded based on the severity and impact of their findings, with bounties ranging from $150 to $3,000. Neon's commitment to collaboration and continuous improvement in cybersecurity is demonstrated through this initiative, aiming to create a resilient and secure platform for its users.

Neon has announced the launch of its Bug Bounty Program in partnership with HackerOne to bolster its security measures by engaging with global security researchers and ethical hackers. This initiative aims to identify and address potential vulnerabilities in Neon's serverless platform, enhancing user trust and safety. The program, which features rewards ranging from $150 to $3,000 based on the severity of discovered vulnerabilities, includes both production and staging environments to ensure comprehensive testing. This effort follows a series of three penetration tests in 2024 that uncovered and resolved 58 vulnerabilities, further solidifying Neon's commitment to proactive security. By collaborating with the security community, Neon seeks to create a robust and secure environment for its users, inviting participation from individuals with HackerOne accounts to join the mission of safeguarding their platform.

AWS has recently updated Aurora Serverless v2 to scale down to zero ACUs during idle periods, a feature highly requested by users. This update allows clusters to autopause entirely when no connections are active and wake up automatically in 15 seconds when traffic returns. However, some questions remain about the reliability of the autopause feature, cold start times, handling many connections, and whether this will be enough to address Aurora's high pricing concerns. Alternatives like Neon offer native scale-to-zero features with rapid cold starts and other benefits for developers seeking a true serverless database experience.

Starting December 1st, Neon users will experience reduced storage costs for inactive branches that are older than two weeks and idle for at least a day. This change is due to the introduction of archive storage, which automatically archives inactive data without transferring it. The Pageserver evicts the branch's data from its SSD cache, but the data remains securely stored in cloud object storage. Reactivating an archived branch restores full performance by pulling the data back into SSD storage. Neon will charge archive storage at a reduced rate of $0.1 per GB-month and include a substantial amount of archive storage in their monthly subscription plans for Launch, Scale, and Business users.

This blog post explains how to manage multiple databases using the same schema with DrizzleORM, GitHub Actions, Neon API, and custom template scripts. The Database Per Tenant model is an architectural approach where each tenant (user, client, or project) has its own dedicated database instance sharing the same schema. This method requires new customers to be created using the same schema, and any changes to the database schema must be rolled out to all individual databases simultaneously. The workflow involves three scripts: create, generate, and migrate. The create script automates creating new Neon projects via the Neon API, while the generate script lists all projects in the Neon account, creates DrizzleORM configuration files if they don't exist, generates migration files using Drizzle Kit, creates a GitHub secret for the database connection string, and updates the GitHub Action workflow to include the new secret. The migrate script is automatically triggered by the GitHub Action, running schema migrations for all projects by reading their DrizzleORM config files. This approach can be used for any new projects/customers or when changes to schema are made and works well for database-per-tenant architectures.

Neon has introduced an automatic archive storage feature to reduce storage costs for its users by charging a lower per-GB rate for inactive branches—those idle for at least a day and older than two weeks—starting December 1st. This reduction in costs is achieved by evicting inactive branch data from the high-performance SSD cache, instead keeping it in cloud object storage, which lowers the expenses associated with maintaining constantly active Pageservers and Safekeepers. Although accessing archived data incurs a minor initial performance delay as it reloads into SSD storage, the savings in storage costs are passed on to users, with archive storage billed at a reduced rate of $0.1 per GB-month. The new storage model requires no action from users, allowing them to benefit from cost savings automatically.

The blog post provides a detailed guide on managing schema migrations across multiple databases using DrizzleORM and Neon, a serverless PostgreSQL platform. It outlines the database-per-tenant model, where each client or project has its own database instance with a shared schema, and demonstrates the challenges and solutions for maintaining schema consistency. The post explains a workflow involving the creation of Neon projects via the Neon API, configuration of DrizzleORM files, and automation of schema migrations using GitHub Actions. Three main scripts—create, generate, and migrate—are introduced to automate project creation, configuration, and schema updates, respectively. The guide highlights the use of environment variables and GitHub secrets for managing database connections and emphasizes the potential of using serverless architectures for scalable database management. The article concludes by encouraging readers to explore and adapt the workflow to suit their needs, with the author inviting further discussion on social media.

The Neon Console team migrated from Webpack to Vite, aiming for hot module replacement support, improved build times, and a simpler setup with fewer dependencies. While the migration did not result in faster build times, it achieved significant wins such as HMR functionality and reduced dependencies. A custom proxy using Vite's JS API was implemented to handle HTML generation by the backend. The team also faced challenges like finding the entry point for production assets and supporting multiple SPA apps in a single HTML response. Overall, frontend developers are happy with the new setup, which has simplified configuration across apps, Vitest, and Storybook.

Neon, a serverless Postgres platform, transitioned from using Webpack to Vite for building its Single Page Applications (SPAs) to improve simplicity and efficiency. The migration aimed to support hot module replacement (HMR), improve build times, and reduce dependencies. While the build times with Vite initially did not improve and even slightly increased, the setup became significantly simpler, and the HMR functionality was a notable advantage. A custom Vite proxy was developed to integrate with the backend's dynamic HTML generation, allowing developers to interact with an HMR-enabled app. Despite challenges such as resolving conflicts with API endpoints and issues with the @vitejs/plugin-react-swc extension, the migration unified tooling across apps and improved the development experience. Additionally, patching the Ace Editor dependency reduced the number of modules processed by Vite, speeding up build times by approximately 50%.

The article discusses a multi-tenant RAG pipeline example using Neon's database-per-user design and the multi-tenancy features of the Inngest workflow engine. It addresses the Noisy neighbor problem, where a few customers make up a disproportionate fraction of the system's overall activity, impacting other customers' performance. The solution involves isolating data for each organization and applying guaranteed capacity using dedicated databases and workflows per tenant. This approach ensures fair processing performance by preventing spikes in usage that could affect the application's performance and cost.

In this article, a multi-tenant RAG (Retrieve, Augment, Generate) pipeline is discussed, focusing on the challenges of reliability and security in SaaS applications, particularly the "noisy neighbor" problem, where some users disproportionately affect system performance. The solution presented involves using Neon’s database-per-user design and Inngest's workflow engine for guaranteed data isolation and capacity, ensuring one user's activity does not impact another's performance or access to data. A CRM application example demonstrates how contact CSV files are enriched and embedded into vector stores for semantic search, with each organization assigned a dedicated Neon database and guaranteed capacity through Inngest workflows. The approach includes throttling configurations to handle third-party API rate limits, ensuring fair processing performance for all users. The article highlights how leveraging Neon's and Inngest's features can efficiently manage multi-tenancy without additional infrastructure costs, with a demo available on GitHub for further exploration.

The blog post explores the complexities and limitations of using Row-Level Security (RLS) in Postgres for application authorization, suggesting that while RLS is a powerful tool for preventing cross-tenant data access in multi-tenant applications, it may not be suitable for expressing an app's entire authorization model due to its dense syntax and potential pitfalls, such as infinite recursion and difficulties in testing. The post also discusses the integration of Neon RLS into the Neon Data API and suggests using higher-level frameworks like CASL for more complex data models, while still employing RLS for essential security checks. It highlights the importance of structuring RLS policies correctly to leverage Postgres's optimization capabilities and avoid common errors, and encourages a hybrid approach combining RLS with other frameworks for better security and manageability.

The text discusses the use of Postgres RLS (Row-Level Security) for authorization in applications, highlighting its challenges and benefits. While RLS is not the most expressive or easy to use authorization model, it can be effective when used for core authorization checks such as preventing cross-tenant access in multi-tenant B2B SaaS applications. The text also suggests moving the authorization model to a higher-level framework like CASL as data models become more complex.

The conversation between Raouf Chebri from Neon and Robert Chandler from Wordware explores the challenges and innovations in building AI agents, emphasizing the importance of fast iteration and domain expertise in improving development efficiency. Wordware is highlighted for its unique prompt-first environment, which enhances collaboration between engineers and non-technical team members, allowing for rapid iteration and more effective agent development. The platform is designed for modularity and model-agnosticism, enabling users to leverage different large language models (LLMs) based on specific needs without extensive reworking. Wordware's viral success with a Twitter-analyzing agent demonstrated the flexibility and scalability of using Neon's serverless architecture, which efficiently handled unexpected traffic spikes through dynamic autoscaling and branching capabilities. This case underscores the significance of adaptable infrastructure in AI projects, with Neon providing robust support for startups through its efficient resource management and testing environments.

In a panel discussion with Neon and Wordware, the challenges faced by teams building AI agents were highlighted, particularly managing slow feedback loops. To address this issue, Wordware was developed to allow seamless collaboration between engineers and domain experts within a prompt-first environment. The platform is designed for prompt engineering and supports multiple LLMs, allowing users to leverage the best models for their specific needs without reworking entire systems. Neon's serverless architecture and autoscaling capabilities were crucial in supporting Wordware during a sudden traffic spike, demonstrating the importance of dynamic autoscaling in databases.

Neon has integrated its Row-Level Security (RLS) functionality into the Neon Data API to simplify the often complex process of implementing RLS in Postgres. RLS, which is used to control access to rows in a database table, can be cumbersome and repetitive, particularly for CRUD applications. To address this, a more concise API has been developed, allowing for higher-level abstraction when setting policies for operations such as select, insert, update, and delete. This new API leverages the `crudPolicy` and `authUid` functions from “drizzle-orm/neon,” streamlining the creation of PostgreSQL policy definitions and making it easier to connect user authentication with specific table columns. This approach is designed to be adaptable and useful for any implementation of Postgres RLS, whether on Neon or other platforms, and an upcoming blog post will demonstrate its application in a social media network data model.

Postgres Row-Level Security (RLS) can be challenging to understand and use. A more concise API specifically designed for CRUD apps has been developed, which includes the crudPolicy function with inputs such as role, read, and modify policies. The authUid function is specific to pg_session_jwt and allows connecting auth.user_id to a table column. This higher-level abstraction on top of Postgres RLS aims to assist developers in using RLS effectively. A future blog post will provide a reference RLS implementation for a social media network.

Neon has integrated with Datadog to enhance observability by allowing users to monitor key metrics from their Neon databases directly in the Datadog platform. This integration exposes critical metrics such as database connection counts, replication delays, compute resource usage, and local file cache statistics, which are essential for optimizing performance and ensuring data consistency. The local file cache (LFC) in Neon's architecture serves as an in-memory storage layer to expedite data retrieval, and monitoring its metrics can help identify performance bottlenecks. Additionally, metrics like the working set size in Postgres provide insights into data usage patterns and help optimize resource allocation through autoscaling. Users can also track Postgres statistics, such as row operations and deadlocks, to gain visibility into internal processes and potential optimization opportunities. To facilitate the integration, Neon provides a JSON configuration file for easy import into Datadog, enabling quick access to these performance metrics.

Neon has integrated with Datadog to monitor key metrics of your database during its beta phase. The Business Plan currently supports this integration, and users can request it for the Scale plan as well. Metrics exposed to Datadog include connection counts, replication delay, compute metrics, Local File Cache metrics, working set size, and Postgres statistics. By monitoring these metrics, Neon users can optimize their databases' performance and detect potential issues in replication processes or connection pooling strategies.

The article details the implementation of a secure, user-specific access control model for a social network utilizing PostgreSQL's Row-Level Security (RLS) and the Drizzle ORM. The setup, inspired by Twitter's data model, includes tables for users, profiles, posts, comments, chats, and chat participants, each with specific RLS policies to control access and modifications. The users table is restricted to admin access for synchronization, while the user_profiles table allows users to update their own profiles and view others. Posts and comments allow authors to modify their own content, with public visibility for all. The chat system is more complex, relying on a view to manage participant visibility without recursion issues, ensuring only participants can see chat details, while messages can only be inserted by participants. The article highlights the challenges of writing RLS policies, emphasizing the need for thorough validation to prevent data leaks and suggesting that much of the access logic should reside in the database layer for security.

The text discusses implementing secure access controls for a social network using Postgres' Row-Level Security (RLS) feature and Drizzle ORM. It covers the authorization model for a Twitter-inspired data model, including users, profiles, public posts, private chats, and chat messages. The implementation involved separating users and user profiles tables, setting up RLS policies for posts and comments, and handling complex requirements for private chats. The text also highlights challenges faced during the process, such as writing raw SQL policies, validating RLS policies, testing RLS policies, and pushing down logical constraints to the database layer.

The Replit Agent, a feature within the Replit development environment, allows users to offload coding tasks by interacting with AI through natural language prompts. This automation is particularly useful when working on full-stack applications requiring consistent changes between code and database schema. The Replit Agent can implement end-to-end features in an application, modifying API, Database, and Frontend simultaneously. It provisions a serverless Postgres database (powered by Neon) that scales on demand and builds the rest of the app using Flask, a Python microframework for web applications. Alembic, a database migration tool, is used to track changes in SQLAlchemy models and automatically generate migration scripts for schema updates.

Replit Agent is an advanced feature within the Replit development environment designed to streamline coding tasks through natural language and artificial intelligence, specifically aiding in database migrations for full-stack applications. Utilizing a serverless Postgres database powered by Neon, Replit Agent automates the creation and modification of application components, including APIs, databases, and frontends, primarily using Flask as a framework. The process is enhanced by integrating Alembic and SQLAlchemy to manage database schema changes, allowing developers to input natural language prompts to generate and apply migration scripts automatically. This capability was demonstrated through the creation of a TODO application that incrementally added features like due dates and task priorities, showcasing the Agent's ability to handle both backend and frontend updates effectively. The system maintains database consistency by generating migration files for each change, which can be rolled back using Alembic if necessary, ensuring developers can focus on application building while the Replit Agent manages underlying structural changes.

Honcathon is a virtual event taking place in November, celebrating the Goose and promoting web development using the HONC stack. The HONC stack includes Hono as a web framework, Drizzle as an ORM, Neon as a database, Cloudflare Workers, and Fiberplane for debugging and testing APIs. Participants can choose from four categories to build applications, with winners receiving a €500 Amazon voucher. The event runs until December 15th, with projects designed to take half a day to a full day of work.

The concept of "SQL from the frontend" is a complex topic that offers both advantages and challenges, particularly in terms of security and scalability. While it may not be ready for mainstream use yet, this approach can significantly increase development speed by allowing direct access to data models and reducing inter-team dependencies. However, traditional databases need to implement features such as query allow-listing, automatic generation and maintenance of these allow-lists, rate limiting, and authorization/access rules to ensure safety when using "SQL from the frontend." As this technology continues to evolve, it holds promise for many applications, particularly prototypes.

The concept of "SQL from the frontend" is intriguing yet complex, primarily due to security and scalability concerns. While allowing the frontend to directly access the database can enhance development speed and reduce dependencies between frontend and backend teams, it also raises significant security challenges, such as the need for query allow-listing and rate limiting to protect against attacks. Modern frameworks like Firebase and PostgREST facilitate direct data interaction by providing REST APIs with enforced authorization rules, but they lack the abstraction layer that typically houses sensitive business logic, which could expose credentials and algorithms. Despite these challenges, the approach may suit prototypes and certain applications, and ongoing developments like the Neon Data API aim to address some of these security issues by incorporating features such as Row-Level Security. Companies are exploring this architecture, seeking feedback and ideas for future improvements, indicating an active interest in making this approach viable for more extensive production use.

Honcathon is a new virtual event celebrated in November, designed to fill the gap between October's Hacktoberfest and December's Advent of Code, by focusing on web development with a playful theme centered around geese migration. The event features the HONC stack—comprising Hono as a web framework, Drizzle ORM, Neon database, and Cloudflare Workers—to accelerate web project development, while Fiberplane aids in debugging and testing APIs. Participants can choose from four application-building categories, with a chance to win a €500 Amazon voucher. The event is designed to be accessible, allowing projects to be completed in a half-day to a day, and submissions are due by December 15th.

The integration of Inngest with Neon, a true serverless database, enables users to leverage Neon's Logical Replication for triggering Serverless functions such as Vercel Functions, AWS Lambdas, and Cloudflare Workers from database changes. This new feature unlocks several use cases, including the quickest way to prototype AI workflows, streaming databases into ETL pipelines, and building user workflows that react to database changes. The integration allows developers to build their AI workflows on top of Neon's serverless triggers with just a few lines of code, improving workflow reliability and handling multiple tools and models. Additionally, it enables the addition of reasoning and "Human in the loop" features to AI workflows.

Neon, a serverless database with features like connection pooling and automatic scaling, is enhancing its capabilities by integrating with Inngest to facilitate serverless triggers. This integration leverages Neon's Logical Replication to initiate serverless functions, such as Vercel Functions and AWS Lambdas, in response to database changes. This blog post explores several use cases for these serverless triggers, including AI workflow prototyping, ETL pipeline streaming, and user onboarding workflows. By utilizing Inngest's functionality, developers can efficiently manage AI workflows, automate ETL processes, and implement user onboarding features with minimal code. The integration also supports retriable and cached steps to improve workflow reliability and allows for the addition of concurrency and throttling policies. Furthermore, it provides flexibility for including human feedback in AI workflows and offers a deployable open-source example of an AI agent built with Neon and Inngest.

Invenco, a logistics SaaS company specializing in e-commerce order fulfillment, transitioned from Aurora Serverless v2 to Neon to address challenges with managing serverless traffic and high costs. With AWS Lambda at its core, Invenco's serverless infrastructure faced issues with Aurora, particularly during traffic spikes, leading to dropped connections and insufficient scaling capabilities. Neon, utilizing a connection pooler based on pgBouncer, offered a seamless out-of-the-box solution that handled concurrent requests efficiently, reducing database costs by 80% and improving performance. The migration to Neon allowed Invenco to consolidate non-production services into a single project, simplify data management through branching, and utilize logical replication for minimal downtime during the transition. This setup provided Invenco with a scalable and cost-effective architecture, optimizing operations across its microservices-based framework and supporting its growth in the competitive e-commerce logistics sector.

Invenco, a logistics SaaS company, migrated from Aurora Serverless v2 to Neon due to technical challenges and high costs with the former. By using Neon's connection pooler based on pgBouncer, Invenco reduced database costs by 80%, improved performance, and ensured smooth operations during high-traffic events. The company's serverless architecture is built around AWS Lambda, which handles spiky traffic typical from e-commerce. Neon's pooled connection management worked seamlessly with hundreds of concurrent requests without the bottlenecks experienced in Aurora Serverless v2. Additionally, Neon costs Invenco approximately 1/6 of what they paid with Aurora.

Neon, an innovative company with a history of supporting experimental ideas, has recently incorporated AI-driven features into its SQL editor to enhance the user experience. These features include SQL generation, which allows users to input natural language prompts to generate SQL queries, and an error-fixing tool that leverages AI to correct mistakes in SQL queries. Additionally, query name generation uses AI to assign meaningful names to queries. Despite these advancements, Neon has opted not to implement an "AI assistant" chat interface, preferring to maintain control over the user experience and provide actionable elements in context. The company has been experimenting with different AI models, currently using Claude 3.5 Sonnet by Anthropic, and highlights the benefits of using cloud-based AI providers over self-hosting, particularly for smaller projects. Neon encourages users to try these new features and shares insights into the infrastructure and streaming capabilities that support AI integration.

Neon has introduced AI-driven features into their SQL editor, including SQL generation, query name generation, and error fixing. These features leverage large language models (LLMs) to assist users in writing SQL queries. The company experimented with multiple LLMs before settling on Claude 3.5 Sonnet by Anthropic. Neon chose not to implement an AI assistant due to the complexity of making it useful and the desire for a tailored user experience. The company also shared insights into choosing between self-hosted and API providers, as well as streaming HTTP responses.