Stripe Data Pipeline now supports real-time sync to Postgres. Connect Neon from the Stripe Dashboard and query live payment, subscription, and customer data next to your app data, without building API or webhook integrations.

Neon Realtime is live in public beta. Any SQL query can now be a live query. Subscribe to it and the result stays up to date as your data changes. That makes your whole app reactive, with no polling or refetch logic.

Lakebase Search is the search primitive of the Neon backend. One of the best things about it is that it ranks keyword results with BM25. That said, BM25 can only score the terms it's given.

A photo library looks simple, but each photo carries files, metadata, vectors, and an owner. Atlas is a TanStack Start app that keeps all of it on the Neon backend, so one branch gives you a full preview of the app.

Database storage on the Neon Free plan is now 1 GB per project, up from 0.5 GB. You still get 100 projects, with existing projects getting the new limit automatically.

Neon AI Gateway now serves embedding models on the same OpenAI-compatible endpoint and with the same credential you already use for chat. Generate vectors, store them in Lakebase Postgres, and query them with Lakebase Search, all inside one Neon branch.

@neon/effect brings the Neon SDK to Effect. Provision projects and branches, handle tagged errors and compose infrastructure workflows with retries, cancellation and timeouts.

PII redaction in Postgres today works column by column. Its limitation is that it only works when each piece of personal data has its own column, which is rarely the case with free text.

Earlier this year, we had two incidents in one week. After those incidents, we doubled down on reliability. This post summarizes the reliability work we've been rolling out since then to keep uptime high as our fleet, product, and customer base grow.

Build the search engine, ingestion layer, and serving layer for agent retrieval with Lakebase Search, Functions, Object Storage, and AI Gateway.

Skydive is a platform that lets teams build AI coworkers that do real work. When a Skydive agent needs a durable state, it deploys an isolated Neon backend mid-task, with no human in the path, and it takes it around a second.

Restores are broken in managed OLTP, and they have been broken for a long time. They are slow, and they get slower with scale. The databases that need recovery most, the large production ones, are the ones left waiting the longest.

Now that we've announced GA for Neon's complete backend, one of the things we're most excited about coming next is adding realtime to the Neon platform. Not least because it's being worked on by the team from Electric, who recently joined Neon at Databricks.

A file in a bucket is just bytes; when you upload it, there is often a job to do next with that file, and that job usually involves Postgres - a `files` row, a status, a thumbnail key. That is a perfect Neon Functions job; the missing piece was something to start the Function when the object appeare...

During the beta phase, the only way to run a Neon Function was to send it an HTTP request. That works well for jobs triggered by your app, but not so much for backend jobs. If you wanted to pull an external API into Postgres every 15 minutes, you needed an external scheduler. Also, using pg_cron mea...

During beta, each Function was reachable only at its Neon invocation URL, something like `https://br-cool-forest-a1b2c3d4-api.compute.c-2.us-east-2.aws.neon.tech`. Now, we support custom domains - you can put it behind `api.example.com` instead.

Neon is now a complete suite of backend primitives built around the database and rooted on the lakebase architecture: Lakebase Postgres, Object Storage, Functions, Managed Better Auth, and AI Gateway. All tools are GA and ready for production. Tell your agent to deploy them.

It took six days to go from zero to isolated Postgres per tenant, provisioned the moment someone pays. A traditional Postgres setup would have been a full quarter of work.

Claimable Neon implements the anonymous registration method in auth.md, the open agent registration protocol authored by WorkOS, to give agents a way to provision a temporary Neon project without creating an account or collecting payment details.

On large fixed-size Lakebase Postgres computes on Neon, we now put most of the machine's memory into Postgres shared buffers and back that cache with huge pages. Hot pages stay in DRAM instead of falling through to a local disk cache, so the same working set is served faster and with less CPU.

If headcount is often a company's largest cost, tokens will be a close second soon as agents take on more work. Imagine how much $$ a software company will be able to save just by pre-selecting models that are efficient to run, especially in large companies with many engineers using coding agents.

Today we're launching @neon/tools, a package that turns the @neon/sdk ergonomic client into typed agent tools with adapters for MCP, Mastra, and Eve. We're also using it to expand the hosted Neon MCP Server.

Neon is now available as a plugin in Grok Bot. You just have to connect your Neon account once and you'll be able to ask a Grok bot to build on Neon.

Most hosted Postgres pricing works like this: you pick an instance size, the vendor assumes the instance will run for about 730 hours a month, and you pay for those hours. Lakebase Postgres addresses that waste with autoscaling and scale to zero.

Choosing a database instance size before you know the workload is an old building pattern. Lakebase Postgres omits the sizing experience altogether thanks to autoscaling.

Today we're launching Neon Labs, a home for experimental tools built around Lakebase Postgres. We want Neon Labs to be a playground for ideas that could help the broader Postgres community.

The Neon CLI moved fast over the last couple of months. It is a key tool for agents, who do all the work without ever opening the Console - let’s take a look at some of recent changes.

Agents treat code as lightweight: branch it, deploy it, throw it away. The infrastructure under that code should work the same way. Working with an OLTP database is traditionally heavy and full of friction, but very little of that is a Postgres problem.

Open-weight models are built for performance, but how they're served determines whether end users actually feel that speed. Neon AI Gateway calls Databricks Foundation Model APIs for Databricks-hosted open-weight models, a stack that has years of inference engineering behind it.

We keep expanding our backend observability - the most recent addition: you can now query backend logs outside the Console! neon logs reads what Neon Functions and Object Storage emit on a branch, with filters for source, severity, and message text.