February 2025 Summaries

The era of "it works on my machine" has come to an end as local development environments have evolved significantly over the years. In the 1990s, developers had to manually set up and manage their own systems, leading to deep technical understanding and creativity. The 2000s saw the rise of standardized local development environments through *AMP stacks, which provided one-click installations for web servers, databases, and frameworks. Docker introduced containers in the 2010s, revolutionizing local development with lightweight, isolated environments that package everything an application needs to run. Today, hosted environments have become the norm, with cloud services providing fully managed Postgres instances, developer-friendly workflows, and collaborative features like branching and real-time debugging sessions. The future of local development is shifting towards ephemeral, cloud-native tools that blur the lines between development, operations, and collaboration.

Nick Turley, Head of Product for ChatGPT at OpenAI, is joining Neon's Board of Directors to help shape the evolution of fundamental internet infrastructure in the age of AI. The shift towards software development comes as a result of key product launches from customers like Replit and Create.xyz, which have started spinning up new databases and instances every few seconds, leading to an unprecedented scale of database creation. This is driven by advancements in code-generation tools enabled by Large Language Models (LLMs), allowing developers to go from a prompt to a fully functioning application in minutes, with the game being on that most new applications will be started with AI agents for at least the first 10-100 iterations. The introduction of SAI agents introduces new demands on infrastructure, including parallelism at scale, instant deploys and forkable environments, strong isolation, and full-stack integrations. With Nick Turley's leadership, Neon aims to refine its strategy and build infrastructure that meets the demands of this future, where the scale will be massive and AI-generated code is unpredictable.

Nick Turley, Head of Product for ChatGPT at OpenAI, has joined Neon’s Board of Directors, bringing valuable product leadership experience from his previous roles at OpenAI, Instacart, and Dropbox. This appointment coincides with a transformative period for Neon, marked by the separation of storage and compute for Postgres, which enabled features like instant provisioning and autoscaling, resulting in the deployment of over 750,000 databases by the end of 2024. The rise of AI-driven code generation, exemplified by Replit Agent's ability to generate code and provision infrastructure, has significantly increased the creation of databases through automated means. As AI agents increasingly take on tasks such as code writing, deployment, and infrastructure setup, the demand for robust, scalable, and secure infrastructure grows. Neon's focus is on developing infrastructure that supports this shift, emphasizing features like high-volume parallelism, instant deployments, and secure sandboxes. Turley's leadership is anticipated to guide Neon in refining its strategy to meet these evolving needs and shape the future of developer and agent infrastructure.

The evolution of development environments from the 1990s to the 2020s highlights a shift from complex local setups to cloud-based solutions, driven by the need to address issues like environment drift and manual configuration challenges. Initially, developers had to manually install and configure components like Apache and Postgres, leading to a deep understanding of system architecture but also to the notorious "it works on my machine" problem. The 2000s introduced standardized stacks like XAMPP, simplifying setup but still requiring manual dependency management. Docker revolutionized the 2010s by enabling containerization, allowing for consistent environments across machines and bridging the gap between development and operations. In the 2020s, the focus shifted to hosted environments, where services like Neon provide managed database solutions, allowing developers to work without local installations and ensuring parity with production environments. This transition has also been accompanied by the rise of cloud-based development platforms that enable real-time collaboration and eliminate the need for local infrastructure, underscoring a trend towards ephemeral and scalable development practices.

Docker Compose has emerged as a standard solution for testing applications with Postgres, providing isolated, consistent databases to test against. However, as testing requirements grow more complex, teams often discover the limitations of this approach, including cumbersome data population, managing test data between runs, and CI pipelines slowing down due to repeated database instance spinning up. Despite its benefits, Docker Compose has shortcomings such as populating larger datasets for testing, persistence issues with cleaning up containers and volumes after testing, and resource consumption due to running local databases. Database branching offers an alternative approach by creating isolated copies of the database using copy-on-write mechanics, providing instant test environments, parallel testing, and clean-up automation. The choice between Docker Compose and database branching depends on team needs, with many teams successfully leveraging containers for local development while using branches for CI/CD pipelines and complex testing scenarios.

Deploying Postgres for testing with Docker Compose is a common practice due to its ease of setup and consistency across development environments, but it presents challenges as testing needs become more complex. Limitations include cumbersome data population, unintended data persistence between runs, and resource consumption issues, which can slow down CI/CD pipelines and large-scale projects. An alternative solution is database branching, exemplified by Neon, which applies Git-like principles to create isolated database copies that share storage but maintain complete isolation. This approach offers advantages such as prepopulated test data, clean test states, and resource efficiency, making it a scalable solution for modern testing environments. While Docker Compose remains useful for local development, database branching provides a more efficient option for CI/CD pipelines and complex testing scenarios, reflecting a broader shift in how development environments are managed.

The text discusses how to build a secure project management web application using Next.js and Clerk, a user management platform. The application will use server actions to interact with the database securely and protect access to routes using Clerk's middleware. The application will also use a Zustand store to synchronize data across client-side components. The article covers features such as creating organizations, rich text editors for project notes, commenting on projects and tasks, automatic RAG functionality, inviting users from outside the organization, event notifications, and editing and deleting tasks and projects. The article emphasizes the importance of considering security best practices throughout the development process.

The article outlines a comprehensive guide on building a secure project management platform using Next.js, Clerk, and Neon, emphasizing a security-first approach to web application development. It addresses common security breaches caused by misconfigurations, such as exposed database credentials and unprotected API routes, and offers solutions like using Clerk's user management platform to ensure authentication and protect routes. The article details the construction of Kozi, a collaborative project and knowledge management tool, including features like team management, a collaborative text editor, and task notifications. It explains the implementation of server actions to securely interact with the database, ensuring data is only accessible to authorized users. Moreover, it highlights the configuration of protected routes with Clerk middleware and the integration of a serverless Postgres database instance from Neon with Prisma as the ORM for data manipulation. The guide provides a step-by-step process for setting up the database, configuring the application, and managing tasks and projects securely. It concludes by stressing the importance of incorporating security considerations from the outset of application development.

Vapi is a platform that enables developers to build voice AI apps with ease, integrating state-of-the-art language models and text-to-speech engines. It offers advanced voice capabilities, including function-calling features and multilingual support for 100+ languages. Vapi's infrastructure supports real-time performance, scalability, and flexible deployments, making it suitable for applications with spiky traffic patterns. The platform uses Neon, a serverless Postgres solution, to power its business-critical workloads, providing autoscaling and connection pooling capabilities. With Vapi, developers can build voice AI agents that converse naturally and dynamically, reducing complexity and focusing on building without the hassle.

Vapi leverages Neon, a serverless Postgres platform, to enhance its AI voice agents' capabilities, allowing them to handle dynamic and unpredictable workloads efficiently. By integrating advanced language models, text-to-speech engines, and telephony infrastructure, Vapi enables developers to create AI-driven voice applications that can perform tasks such as booking appointments and providing customer support, all while supporting multilingual interactions. Neon's autoscaling features and connection pooling, built on PgBouncer, ensure Vapi's systems can manage thousands of concurrent calls without performance issues. Additionally, Vapi streams data from Neon to ClickHouse via PeerDB for comprehensive log analysis and reporting, allowing for an integrated view of structured call data and raw logs. This setup allows Vapi to scale its operations seamlessly, catering to varying customer demands and providing reliable service across different use cases.

You can now use Neon's Native Vercel Integration to automatically create a database branch for each Vercel preview deployment, eliminating the need for manual data population and schema migrations. This integration provides isolated databases for every preview deployment, preventing conflicts and leftover test data. You can also reset environments with just one click, saving valuable development time. To set up this feature, you'll need to connect your Vercel project to your Neon database in Vercel, select the desired environments, enable advanced options, and click "Connect". With each commit to a branch in your GitHub repository, Vercel preview deployments will be created with their own Neon branch, ensuring seamless testing of application and schema changes.

Neon Auth is a fully managed authentication solution integrated into the Neon platform, allowing users to provision an auth solution directly from the Neon console in seconds. It provides full portability and can be easily transferred to an external account if needed. Neon Auth works as an automated provisioning and synchronization layer between an authentication provider and the Neon database, keeping user profiles in sync automatically without requiring extra code or background jobs. The managed layer approach prevents vendor lock-in, allowing users to retain control over their authentication layer even if their deployment changes in the future. With Neon Auth, users can simplify authentication and user data management by referencing auth data as a standard Postgres table, making it easier to build admin consoles, dashboards, and cron scripts.

Vercel users can now utilize Neon’s Native Vercel Integration to automatically create a database branch for each preview deployment through the Vercel Marketplace, simplifying the management of database environments during development. This integration helps avoid conflicts and leftover test data by ensuring that tests in one preview deployment do not affect others, and it allows for instant setup of databases through a copy-on-write mechanism, eliminating the need to manually populate them with seed data. Developers can integrate schema migrations directly into their deployment process, ensuring that changes are applied automatically to the database branch, and can quickly reset environments with a single click if necessary. To set up this integration, users need to connect their Vercel project to a Neon database and configure the deployment settings to create a database branch for each preview, significantly enhancing development efficiency and reducing manual cleanup tasks.

Neon Auth is a newly introduced fully managed authentication solution within the Neon platform, designed to streamline the process of provisioning authentication services with a few clicks while avoiding vendor lock-in. By using Stack Auth as the initial provider, Neon Auth automates the synchronization of user profiles with your Postgres database, eliminating the need for manual synchronization methods like webhooks or background jobs. The system allows users to retain full control over their authentication layer, even if they transition away from Neon, by storing authentication data directly in the database, which facilitates easier migration between providers. Neon Auth simplifies user data management by exposing user data as a standard Postgres table and ensures continuous synchronization with sub-second delays, promoting seamless integration of authentication into applications. The service is currently in Beta and aims to expand with additional authentication providers like Clerk, offering more options for users in the future.

Neon's superpower: Instant Point-in-Time Recovery (PITR) allows for the creation of a new branch at any point in time, enabling instant recovery of a dropped table without losing fresh data. This is made possible by Neon's copy-on-write storage model, which references existing storage pages until changes are made, resulting in near-instant recovery times of approximately one second, even for massive databases. Two recovery routes are available: Route 1, where production remains online and the missing table is copied from a PITR branch, and Route 2, where production is switched to the recovered branch without downtime. Neon's approach shines at scale due to its instant PITR, recover from an exact time using Time Travel, and point production to a restored branch without restarts. In contrast, AWS RDS Postgres relies on automated snapshots and WAL replays for PITR, resulting in slower recovery times that can take hours for large databases.

Neon offers an innovative solution for database recovery through its Instant Point-in-Time Recovery (PITR) feature, which allows users to restore a multi-terabyte production database to a precise moment before an inadvertent table drop. This is achieved by creating a new branch, ensuring that the main branch remains operational and continues to ingest new data without disruption. The restoration process is nearly instantaneous, taking about one second regardless of database size, due to Neon's copy-on-write storage model that references existing storage pages until changes occur. Unlike traditional methods used by AWS RDS, which require time-consuming snapshot restoration and WAL replay, Neon's approach allows for immediate access to the restored branch, making it highly efficient for large-scale databases. Users can choose to either keep production as is and copy the missing table from the PITR branch or switch production to the recovered branch, depending on their need for post-drop data. Neon's ability to handle these operations seamlessly and quickly has made it a favored choice for thousands of teams, as it significantly reduces downtime and ensures data availability.

SQLite is a lightweight and simple database technology that is widely used due to its widespread adoption in various platforms, including Android phones, iPhones, browsers, Macs, and Windows machines. Its simplicity and low overhead make it suitable for testing purposes, allowing developers to spin up new databases for each test, run queries in isolation, and tear them down quickly without worrying about cleanup or state persistence. However, SQLite's differences from Postgres can lead to false confidence in tests, as SQL dialects, data types, and behavioral quirks can vary between implementations. Neon is a cloud-native Postgres solution that combines the simplicity of SQLite with the correctness and power of a real Postgres engine, offering features such as ephemeral branching, serverless architecture, and genuine Postgres performance characteristics, making it an attractive option for developers who want fast feedback loops without sacrificing production fidelity.

While SQLite is widely used for testing due to its simplicity and lightweight nature, it presents several challenges for developers working with Postgres, primarily due to differences in SQL dialects, data type handling, and database architecture. SQLite's forgiving nature with data types and its in-memory operations can lead to false confidence when transitioning to the strict type constraints and client-server model of Postgres, which can result in unexpected issues in production. Postgres offers advanced features such as rich JSON support, native array types, and sophisticated concurrency control, which SQLite lacks. To address the limitations of using SQLite for testing Postgres-based applications, Neon provides a cloud-native, serverless Postgres solution that combines the simplicity of SQLite with the robustness of Postgres, allowing developers to spin up ephemeral Postgres databases quickly and conduct tests with the same engine used in production. Neon's architecture supports isolated branching for parallel test suites, real Postgres features, and effortless integration with CI/CD pipelines, ensuring that developers can achieve fast feedback loops without compromising on production fidelity.

AI agents are becoming increasingly active participants in data management, allowing users to interact with their data using natural language queries. A multi-agent AI system is proposed, where multiple agents work together to accomplish tasks, each with a specific role and communicating with others to share information and coordinate actions. The system combines four technologies: Azure OpenAI GPT-4o for understanding natural language, LangChain for converting text-based user requests into structured database queries, AutoGen for managing multi-agent orchestration and coordination, and Neon Serverless Postgres for storing CRM and shipment data. By using these technologies, users can build a simple yet powerful AI solution that not only retrieves data but also performs actions, such as creating new shipments or adding customers to the system. The proposed system allows for low-code development of agentic workflows and provides features like branching and row-level security to manage AI agents and their access to data.

Zap.xyz is a new crypto aggregation platform that processes millions of messages from community channels like Telegram, and by tracking social sentiment and correlating it with on-chain trades, Zap tells you what’s trending in the crypto space and how that’s translating into market movement. To deliver real-time insights to crypto traders, Zap has to reliably capture and act on a huge stream of incoming messages. This all has to be done with a small team hyper-focused on shipping. Initially, Zap attempted to build their CDC pipeline on AWS, but they soon discovered the first hiccup - Aurora Serverless didn't natively support database change streams, forcing them to try to implement this on provisioned Aurora with AWS' Database Activity Streams and AWS SNS. However, adopting a new architecture using Neon, Inngest, and Vercel eliminated unnecessary infrastructure management while ensuring their system could scale. Each tool solves a key piece of the puzzle: Neon is a serverless Postgres database that eliminates manual scaling, Inngest provides an out-of-the-box CDC pipeline, and Vercel gives Zap the ability to deploy serverless functions with minimal overhead. With this new architecture, Zap can now focus on scaling without the pain of wrangling all the AWS tools.

Create is a full-stack development platform that enables users to build production-ready apps quickly and efficiently. With its agent technology, Create can generate code for the entire app in seconds, including UI, backend functions, and database setup. This speed of provisioning and serverless scale-to-zero capabilities are critical for applications that require rapid iteration. Create's end-to-end approach ensures that apps are fully functional from start to finish, without requiring users to manually manage integrations or schema migrations. The platform integrates with Neon, a serverless Postgres database that provides fast, iterative workflows, autoscaling infrastructure, and support for branches, making it an ideal fit for AI agents. With Create, users can build apps quickly and efficiently, while maintaining control over the UI and logic, and deploying them on developer-grade infra.

Create, an AI-driven platform, transforms text prompts into fully functional applications by leveraging its ability to deploy over 50 APIs and integrate with various tools like OpenAI and Anthropic. This platform emphasizes speed and end-to-end functionality, enabling users to see, test, and refine apps in real-time without delays. It simplifies the integration process by allowing users to describe their needs, which the agent then executes seamlessly. Create's capabilities are enhanced by the integration of Neon, a serverless Postgres database that is crucial for fast, iterative workflows. Neon's branching model allows for isolated schema migrations, enabling developers to test changes without affecting production, thus facilitating dynamic updates in response to user inputs. This synergy between Create and Neon ensures a scalable, cost-efficient environment that supports rapid iterations and deployments, making app development accessible to a wider audience.

Building a multi-agent AI solution using Neon Serverless Postgres, LangChain, AutoGen, and Azure OpenAI enables advanced data management by allowing AI agents to both query and perform actions on databases. This approach uses a collection of specialized agents, each with distinct roles and access privileges, to manage shipments, customer, and product information efficiently. By leveraging technologies like LangChain for converting user requests into structured database queries and AutoGen for agent collaboration, the system facilitates tasks such as creating shipments or managing customer information. Neon provides a robust platform for this setup with features like branching to safely test AI-generated queries without affecting the main database, and its serverless model supports thousands of databases without incurring costs for inactive ones. This setup ensures that each AI agent operates within its domain, maintaining data integrity and enabling scalable, low-cost AI-driven data management solutions.

Zap.xyz, a crypto aggregation platform currently in beta, has developed a serverless change data capture (CDC) pipeline using Neon and Inngest to efficiently process millions of messages from platforms like Telegram and soon Twitter. Initially, Zap attempted to use AWS for their CDC needs, but found the process cumbersome and time-consuming due to the lack of native support for database change streams in Aurora Serverless. Seeking a more streamlined solution, they transitioned to Neon, a serverless Postgres database that offers automatic scaling and connection pooling, and Inngest, an eventing framework that integrates directly with Neon's logical replication to trigger workflows without additional overhead. This setup enables Zap to focus on rapid development and product iteration, deploying serverless functions via Vercel for lightweight tasks, while dedicated servers handle high-volume events. This architecture allows Zap to scale effectively and maintain a lean infrastructure, aligning with their core philosophy of building fast and iterating often.

A Neon Twin is a copy of a production database, isolated from the main environment, allowing developers to work on new features or track bugs without affecting the live database. This process involves creating a scheduled GitHub Action that performs a partial data dump of the production database and restores it to a Neon Serverless Postgres instance. The action uses environment variables to securely store connection strings for the production and Neon databases, and includes steps to install PostgreSQL, set the binary path, dump schema, dump data, drop tables and schema, restore schema, and restore data. By using a Neon Twin, developers can create isolated environments that mirror staging or production, making it easier to develop and test new features without affecting the live database. Additionally, plans are in place to anonymize sensitive data whenever a branch is created, further securing the workflow.

Creating a Neon Twin allows developers to safely work with production data by using a partial copy of the production database without migrating it, thus avoiding complex and costly workflows. This approach involves setting up a recurring GitHub Action that performs a partial data dump from a Postgres production database and restores it to a Neon Serverless Postgres instance. Key steps include installing the necessary PostgreSQL version, dumping schema and data, cleaning the database, and restoring the schema and data to the development environment. The process ensures that foreign key constraints are maintained and involves modifying data extraction and restoration steps to ensure integrity. The GitHub Action requires secure connection strings stored as GitHub secrets. While using production data in development can raise privacy concerns, partial dumps and upcoming solutions for anonymizing sensitive data aim to address these issues, enabling effective and secure testing in isolated environments.

GitHub Copilot burst onto the scene and now developers are looking for AI-driven integrations that bring their platforms' endpoints and best practices directly into their coding workflow. Layer can help create a Copilot extension in any language, seamlessly injecting your product's intelligence into GitHub Copilot and other AI surfaces. The process involves installing system prerequisites, such as Python and Ngrok, setting up webhook subscriptions like building a Discord bot, creating a server that handles HTTP requests from GitHub, exposing the local development server to the internet using Ngrok, registering a Github App for the subscription, and finally, installing and using the extension. Layer provides a unified platform for managing LLM extensions, handling Copilot, VS Code, OpenAI GPTs, Anthropic MCP, and beyond, allowing developers to focus on building a great user experience instead of juggling integrations.

Building GitHub Copilot extensions using Layer involves creating a server that handles HTTP requests and subscribing it to GitHub events, which allows AI-driven integrations to deliver platform intelligence directly into developers' coding workflows. The process is likened to building a Discord bot, where a server can be written in any language and is not limited to specific tech stacks. The server processes incoming requests, allowing for customization such as user authentication or data retrieval from databases. After creating the server, a GitHub App must be registered to define where GitHub Copilot should send requests. The tutorial highlights using tools like Python, Ngrok, and FastAPI to set up and expose the server to the internet, and emphasizes the potential for Layer to manage various AI extensions across platforms, simplifying the integration process for developers.

The Tenant AI Chat Solution Accelerator is a ready-to-use template that provides a private and secure AI-powered chat application for each user, complete with custom personas, API extensions, document uploads, and voice interactions. It uses Azure services such as Neon Serverless Postgres on Azure to deploy a private chat tenant in the organization's Azure subscription with a dedicated database per user. The solution features flexible authentication options, AI-powered conversations, customizable personas, extensions support, and voice integration, making it suitable for internal teams or customer support applications that require data residency and compliance requirements.

As seed files are scripts that populate a database with initial data, their management requires intentional organization to ensure proper functionality across development, testing, staging, and demo environments. To maintain database seed files, it's essential to separate environments, automate the process, structure by environment, make seeds incremental, and make seeds idempotent. However, seed files can become a source of friction in development due to maintenance overhead, environmental inconsistency, and referential integrity management issues. Alternative approaches like factory bots provide a programmatic alternative to static seed files, addressing these core problems, but may not be suitable for production data initialization or complex data scenarios. Another option is database branching, which allows creating isolated copies of the database that share the same underlying storage but can evolve independently, offering data and schema branches with varying trade-offs.

Neon has introduced instant database branching, allowing developers to work and test in isolated environments with complete copies of production data. This feature has been successful, leading to the introduction of schema-only branches, which include only the structure that defines the tables and their data types, providing a solution for sensitive data. Later this year, anonymized branching will be launched, enabling the anonymization of sensitive data whenever a new branch is created with data. Instant schema-only branches are available in the Early Access Program and will soon be released to all users.

Neon's API versioning allows developers to create multiple versions of an API with different database schemas, enabling gradual rollout of new features while keeping existing APIs functional. By using Neon's branching feature, developers can dynamically manage database versions and serve different datasets based on the API version. The guide demonstrates how to implement this project by creating a FastAPI backend service that connects to different database branches using Neon's API, and provides step-by-step instructions for setting up the project, connecting API versions to correct database branches, and testing created branches. With Neon's serverless Postgres platform, developers can ship faster via instant provisioning, autoscaling, and database branching.

The Tenant AI Chat Solution Accelerator leverages Neon Serverless Postgres on Azure to provide organizations with a framework for deploying tenant-specific, AI-powered chat applications that prioritize data privacy and security by isolating each user's data in separate databases. This solution enables users to engage in secure conversations with internal documents or APIs without relying on public AI services like ChatGPT, supporting features such as customizable personas, voice interactions, and API extensions. Utilizing various Azure services, including Azure OpenAI, Azure Key Vault, Azure Blob Storage, Azure App Service, and Azure Speech Service, the accelerator allows for enterprise-ready deployment with flexible authentication options and a customizable chat experience. Developed with tools like Node.js, Next.js, and Tailwind CSS, the solution offers an accessible entry point for organizations to create private chat environments, with deployment options available through Azure Developer CLI or Azure Portal, and cost management strategies to optimize resource usage.

Neon has introduced instant schema-only branches, building on the database branching capabilities announced in December 2022, which allow developers to work in isolated environments with either full data and schema copies or schema-only versions. Schema-only branches, suitable for strict PII policies, contain just the database structure and are ideal for creating safe development environments by integrating synthetic data. While these branches help navigate privacy concerns, they may complicate the workflow by necessitating additional seeding steps. Neon is also working on enabling anonymized branching to further address data sensitivity issues, aiming to provide seamless and effective database management solutions akin to modern development tools. Currently available to Early Access Program users, schema-only branches will soon be accessible to all Neon users.

Seed files, essential for populating databases with initial data, become complex as systems scale, requiring careful management and organization. These files, often stored in YAML format, should be treated as integral parts of the codebase, necessitating version control, regular updates, and synchronization with schema changes to avoid disruptions across different environments. Automation of seeding processes, structure by environment, and ensuring seed idempotency are recommended practices to minimize maintenance overhead and prevent data-related issues. However, seed files can cause performance degradation and maintenance challenges, leading some to consider alternatives like factory bots for dynamic data generation in test settings or database branching for isolated database copies. Database branching, offered by platforms like Neon, provides options for both data-inclusive and schema-only branches, facilitating testing and debugging with real or synthetic data while addressing the limitations of traditional seed files.

AWS RDS provides two primary mechanisms for failure recovery: snapshot-based backup and recovery (with WAL replay) and multi-AZ standbys. However, these mechanisms have limitations, particularly at large scales. For example, restoring a 100 TB snapshot and replaying WAL can take hours, while replication lag in Multi-AZ mode can lead to stale data and downtime. In contrast, Neon's managed Postgres service offers instant point-in-time recovery (PITR) without snapshot restores or WAL replays, built-in high availability without dedicated standby instances, and storage-level redundancy. Neon eliminates the need for full-size replicas, ensuring multi-AZ redundancy without doubling costs, and provides a safer recovery process with time-travel queries. By using Neon, teams can achieve faster PITR, reduce infrastructure costs, and minimize single points of failure, ultimately preserving trust and revenue.

The challenges of recovering a 100 TB Postgres database in AWS RDS highlight the limitations of traditional recovery methods, such as snapshot-based backup and Multi-AZ standbys, in large-scale environments. AWS RDS offers point-in-time recovery (PITR) through snapshots stored in Amazon S3 and WAL replay, but this process can be slow, taking hours to restore significant amounts of data. Multi-AZ deployments provide high availability through redundancy but do not address PITR, and they may experience replication lag at large scales. Neon offers an alternative with its innovative Postgres architecture, featuring instant PITR and built-in high availability without dedicated standby instances. By separating storage and compute, and using a log-structured storage system, Neon enables fast recovery and efficient data management, making it a cost-effective and reliable option for managing large databases.