September 2026 Summaries

Neon describes a reliability program for Lakebase Postgres, whose control plane manages millions of databases across Neon and Databricks, three cloud providers, more than 30 regions, and over 70 isolated deployment cells. After two incidents triggered by external dependency failures created self-reinforcing control-plane outages, the company adopted more rigorous postmortems focused on measured customer impact, detection and mitigation times, evidence-based root-cause analysis, and specific, owned remediation items. Resulting work included more than 30 fixes involving the control plane’s Postgres queries and transaction handling, inherited library and network defaults, queue processing, backpressure, and fairness under load. Neon also introduced a preventive framework that scores changes by probability and impact, applying proportionate reliability checks during design, development, release, and operation, such as premortems, load and failure testing, staged rollouts, SLO monitoring, rollback validation, and on-call drills. Future efforts include failure-mode and fault-tree analysis plus automated stress, limit, and recovery testing to identify weaknesses before customers are affected.

Lakebase Search, now generally available on Neon’s Lakebase Postgres platform, provides vector, BM25 full-text, and hybrid search capabilities intended for AI agents without requiring data to move to a separate search system. Its lakebase_vector extension uses hierarchical IVF and RaBitQ quantization with durable indexes stored in object storage, allowing compute to scale independently, suspend when idle, and remain compatible with pgvector queries and data types. The lakebase_text extension adds BM25 ranking and top-K query support while preserving standard Postgres full-text types and operators, enabling combined semantic and exact-keyword retrieval. Neon positions Lakebase Search as part of an integrated retrieval stack that includes Object Storage for source files, Neon Functions for TypeScript-based ingestion and search endpoints, and AI Gateway for embedding generation. Documents can be automatically parsed, chunked, embedded, and indexed after upload, while agents can access hybrid retrieval through a single tool and iteratively refine searches based on returned results.

Skydive, a platform for deploying specialized AI coworkers for tasks such as scheduling, recruiting, support, and coding, uses Neon to give agents rapidly provisioned PostgreSQL backends whenever they need durable state beyond their ephemeral cloud sandboxes. Agents can create isolated databases during tasks in about 0.7 seconds, with an average cold start to first row of 1.13 seconds, supporting uses such as receiving webhooks, hosting internal applications, and retaining data for scheduled routines. Skydive’s API command creates a Neon project and main Postgres 18 branch, places a pooled database connection string in the agent’s secret store, and injects it into the sandbox as an environment variable, while its control plane retains only project and branch identifiers rather than connection strings. The system uses isolated resources and access boundaries between agents, scales compute to zero when idle for cost efficiency, and allows agents to manage database sizes and lifecycle settings through Neon’s API, ranging from small 1 GiB deployments to larger configurations with up to 50 GiB of storage and 4 compute units.

Lakebase Postgres presents branch-based restores as an alternative to conventional managed Postgres point-in-time recovery, which typically requires provisioning a new coupled compute-and-storage instance, copying a snapshot from object storage, replaying WAL, and waiting for data volumes to hydrate. The post argues that this process can take hours for large databases and cites a survey of 50 production Postgres developers reporting frequent critical failures, extended downtime, and limited confidence in recovery. Lakebase separates compute from durable storage: compute runs PostgreSQL workloads and produces WAL, while safekeepers, pageservers, and object storage preserve transaction durability, reconstruct page versions, and maintain immutable history. Because historical database states are already addressable in storage, recovery consists of creating a new independent branch at a selected timestamp rather than copying data and replaying logs. The resulting branch has its own compute and connection string, can be inspected before use, and is described as becoming queryable in seconds regardless of whether the source database is 10 GB or 100 TB. The approach is also positioned for agent-driven workflows, such as associating application checkpoints with database states and enabling rapid undo of code and data changes.

Neon plans to add native realtime data synchronization to its recently launched backend platform, drawing on expertise from the Electric team, which joined Neon at Databricks. Electric co-founder James Arthur says the company concluded that sync is better delivered as a core feature of an established backend platform than as a standalone business, with Neon’s developer adoption and Databricks’ enterprise reach offering a faster path to widespread use. The team aims to address the difficulty of making realtime systems reliable in production, where there is often a tradeoff between flexible synchronization and performance. Its forthcoming Postgres-based realtime service is intended to support mainstream applications and AI agents, integrate with Neon and Lakebase, and include capabilities such as scale-to-zero and database branching. Neon positions the initiative as a step toward a complete Postgres backend that gives developers realtime and end-to-end reactivity as built-in platform capabilities.

Neon has introduced `storage_object_created` triggers, enabling Neon Functions to run automatically when files are uploaded to a specified Neon Object Storage bucket, optionally limited by key prefixes. The event-driven functions receive the bucket name and object key through an HTTP POST, can process files alongside Postgres in the same region, and retain scale-to-zero behavior while supporting long-running work. Suggested uses include cataloging uploads in Postgres, producing image variants, generating AI metadata, extracting and indexing document or audio content, and moderating or redacting uploaded files, though triggers occur after uploads and should not be used as an upload-blocking gate. Because Neon’s infrastructure is branch-scoped, buckets, functions, and triggers are inherited by child branches, but inherited triggers are disabled by default to prevent duplicate processing during development. Developers can provision buckets, functions, and triggers together through a `neon.ts` configuration file, and the feature complements Neon’s recently released scheduled function triggers.

Neon Functions, now generally available, supports custom domains that let developers replace default Neon invocation URLs with branded hostnames for APIs, webhooks, MCP servers, real-time services, and multi-tenant applications. Domains can be registered through the Neon Console, CLI, SDK, API, or configuration files, after which users add a returned CNAME record to their DNS provider; Neon then activates routing and automatically provisions TLS certificates through Let’s Encrypt at no separate domain charge. Each hostname is tied to a specific Function and branch, so preview deployments require separate subdomains rather than inheriting a production domain. The feature is particularly intended for MCP servers, allowing them to run directly alongside Lakebase Postgres with injected database credentials, while avoiding external reverse proxies and providing stable URLs suitable for customer-facing documentation, plugin manifests, and marketplace listings.

Neon has introduced Function Triggers, beginning with cron-based schedules, to automatically invoke deployed Neon Functions for backend tasks while remaining compatible with scale-to-zero Postgres branches. Neon Functions run Node.js code in the same branch and region as a Lakebase Postgres database, with database, Object Storage, and AI Gateway credentials available automatically, making them suited to jobs such as synchronizing external APIs, generating embeddings, cleaning authentication data, resetting staging branches, and reconciling database records with stored objects. Triggers are branch-scoped, inherited by child branches in a disabled state, and can be modified independently to prevent test branches from affecting production schedules. Unlike pg_cron, which runs SQL or Postgres functions inside an active database compute and therefore does not run when the compute has scaled to zero, Function Triggers execute JavaScript or TypeScript functions and can make HTTP requests or access Neon services before writing results to Postgres. The announcement includes an uptime-check example and advises users replacing external schedulers to create idempotent function handlers, validate trigger invocations, use five-field UTC cron schedules, and configure triggers through the Neon API.

Neon has announced general availability of a production-ready backend suite built on its Lakebase Postgres architecture, expanding beyond its original serverless Postgres offering to support AI agent-driven application development. The platform combines branchable Lakebase Postgres, S3-compatible Object Storage, long-running Node.js Functions, Managed Better Auth, and an AI Gateway, with each service designed to share database branching semantics so preview environments and agent sessions remain isolated from production. Neon positions these tools as interoperable primitives rather than a proprietary backend-as-a-service, emphasizing standard interfaces such as Postgres, S3, Better Auth APIs, and model SDKs. Its architecture separates Postgres compute from versioned copy-on-write object storage, enabling instant provisioning, autoscaling, scale-to-zero behavior, and inexpensive branches. Free-plan allocations include database projects and compute, object storage, function capacity and invocations, up to 60,000 monthly active users for authentication, and access to AI models through Databricks Foundation Model APIs at published token prices. Neon also plans to add further backend capabilities, including realtime features, following its acquisition of the Electric team.

LuBot, a solo-founder business analytics chat SaaS, moved from shared Supabase tables to a database-per-tenant architecture to provide stronger customer data isolation across its 52 tables and four schemas. Supabase remains the control plane for organizations, users, and billing, while Neon creates an isolated Postgres branch for each paying customer through a Stripe webhook, runs migrations, stores the connection URL, and routes subsequent requests to that tenant’s database. Deterministic branch names prevent duplicate provisioning during webhook retries, while a centralized tenant resolver ensures application code consistently selects the appropriate database. Neon’s serverless autoscaling and scale-to-zero capabilities make the approach economical by suspending inactive tenant compute after 300 seconds while retaining storage. The implementation also uses Neon’s PgBouncer-backed pooled connections for application traffic, direct connections for migrations and session-dependent tasks, and careful handling of search paths and connection resets to avoid state leakage between requests.

Neon has introduced Claimable Neon, a service that lets AI agents anonymously provision temporary Neon projects without requiring a human account, payment details, or API keys, allowing development to continue when users are unavailable. Built on WorkOS’s open auth.md protocol and its anonymous registration method, the feature gives agents short-lived, project-scoped credentials to create Postgres databases, use the Data API, configure Managed Better Auth, run SQL, and manage branches; additional Neon services are planned. Projects remain unclaimed for up to 72 hours and are limited to 100 MB of storage and 1 GB of transfer, while a human can later use a short-lived claim link to transfer the project into a Neon organization, triggering credential rotation and revocation of pre-claim tokens. Neon selected anonymous registration rather than limiting access to approved agent providers to encourage experimentation while containing risk through limited capabilities, short-lived access, quotas, and a project-scoped API key that is not exposed to agents. Claimable Neon extends earlier ephemeral database initiatives such as neon.new and Instagres, shifts the initial user from developers to agents, and is expected eventually to replace neon.new.

Lakebase Postgres on Neon and Databricks has improved performance for large fixed-size compute instances by allocating up to 75% of DRAM to PostgreSQL shared buffers and backing them with explicit 2 MB huge pages, replacing much of the previous reliance on a local NVMe-based file cache. The change addresses limitations of traditional PostgreSQL caching, including duplicated data in operating-system caches, a former 1 GB shared-buffer cap, and memory-management overhead caused by PostgreSQL’s process-per-connection model. Production measurements report up to roughly twice the throughput, substantially fewer reads from distributed storage, lower latency, and in one case a reduction in CPU use from 20 to 4 cores; benchmark tests also found huge pages could reduce tail read latency by up to 40% and CPU utilization by up to 30%. The configuration is available for fixed computes of at least 18 CU on Neon and 80 CU on Databricks, while work is underway to make shared buffers and huge-page allocation dynamically scale for autoscaling computes. The team also notes a separate earlier optimization that moved full-page image generation to the storage tier, reducing write-ahead log volume and improving write throughput.

Neon compared 42 AI Gateway models on a synthetic workload of 100 customer-support tickets, measuring cost, token use, completion time, and whether responses met seven structured quality requirements involving JSON validity, classification, policy compliance, escalation, wording, and prohibited claims. GPT-5 Nano delivered the lowest cost per usable response and completed the workload in about three minutes, while GPT-5.3 Codex achieved the highest pass rate at 82%; Llama 3.1 8B Instruct was fastest at 1 minute 18 seconds but passed only 34 tickets, and GPT-5.5 Pro was the most expensive at roughly $8.34 and took 57 minutes. Results also showed that Qwen3.5 122B-A10B consumed the most tokens, while open-weight models had substantially lower median costs than proprietary models but somewhat lower median pass rates. The benchmark used isolated Neon branches for each model, a Python runner to submit and grade requests, Postgres for results, and a Next.js web application for reporting, with scheduled reruns planned. The authors emphasize that findings apply only to this workload and reflect real-world variability, but estimate that model selection could create an 86-fold difference in agent inference spending for organizations operating at large token volumes.

Neon has launched @neon/tools, a package that converts its TypeScript SDK into typed agent tools compatible with MCP, Mastra, and Vercel’s Eve framework, allowing developers to expose selected Neon operations without manually creating schemas, retries, or workflows. The package combines OpenAPI-generated Zod schemas with the higher-level @neon/sdk client, aiming to avoid the context overhead and limited usability of direct REST-to-tool generation while bundling common multi-step operations, such as creating database branches and retrieving connection strings, into agent-friendly workflows. It now powers an expanded hosted Neon MCP Server with 104 tools, including 85 Management API tools and 19 manually designed tools for SQL, migrations, diagnostics, documentation, search, and other workflow-oriented tasks. The server supports category filtering, project scoping, read-only access, OAuth or API-key authentication, and result sanitization, while non-read operations and credential-returning reads are marked for host approval.

Lakebase Postgres, powered by Neon, promotes scale-to-zero computing as a way to reduce database costs by suspending compute after inactivity while preserving storage and automatically restarting when needed, complementing autoscaling for continuously active production workloads whose demand varies. The approach is presented as enabling inexpensive ephemeral databases for development, staging, CI tests, preview environments, free-tier users, and the large numbers of backends and branches created by coding agents. Neon also describes extending scale-to-zero principles to backend services including authentication, object storage, functions, and AI gateways, and to vector search through Lakebase Search, which stores indexes durably in object storage so databases can resume without re-indexing. The company says it is also developing realtime synchronization that will not require a persistent replication connection and therefore will remain compatible with suspended compute.

Neon has launched a plugin for Grok Bot that lets users connect their Neon accounts to create projects, manage database branches, execute SQL, review projects and databases, summarize usage, and coordinate work between bots. The integration combines Neon agent skills, which provide workflow context, with the authenticated tools of the Neon MCP Server. A highlighted use case involves safely testing a significant database migration by having Grok Bot identify a selected Neon project, create an isolated production branch, test the migration, and provide the branch ID, pooled connection string, and console link. Users can install the plugin through a deep link, Grok Bot’s Plugins directory, or by asking Grok to connect it.