Neon Postgres

Deploy your app straight from Cursor 🤝 with Lakebase Postgres on Neon already set up

We just launched the Neon Function Registry, a collection of ready-made Neon Functions. Tell your agent to use them in your projects: https://lnkd.in/g3GPpn63 A few templates to start with: - A Chat SDK bot for Slack, Telegram, and the web, built with Vercel's Chat SDK - A Mastra agent with memory in Postgres and a resumable human-in-the-loop workflow - TanStack AI on the Neon AI Gateway, with streaming, tool calling, and structured extraction - Context.dev (YC S26) web data - search the web and news, read pages, and retrieve brand data These templates hand agents pre-built code they would otherwise have to write themselves. Browse the entire collection at https://lnkd.in/gDnFED6s

Building on object storage doesn't mean reading from it. 99.99999% of Lakebase Postgres page reads never touch object storage - they're served from high-performance local caches: https://lnkd.in/g5KVFNqr Object storage is essential to the lakebase architecture: - It holds the database's durable history - Enables one copy for transactions and analytics through LTAP - Gives us 11 nines of durability - Unlocks bottomless scalability with no provisioning, plus branching and instant restores as metadata operations - And it's the perfect partner to stateless compute that scales to zero But there's a common objection to running Postgres on object storage: performance. The argument goes like this: - "Postgres does many small, latency-sensitive reads, - a single object storage read can take hundreds of ms, - so Postgres on object storage must be slow" This assumes the database has to read from object storage to answer queries, and in the lakebase, it almost never does. To illustrate this with numbers, we looked at page read stats across a slice of our production fleet. This is how reads get served: - 𝐂𝐨𝐦𝐩𝐮𝐭𝐞 𝐥𝐨𝐜𝐚𝐥 𝐜𝐚𝐜𝐡𝐞 𝐭𝐚𝐤𝐞𝐬 𝐜𝐚𝐫𝐞 𝐨𝐟 𝟗𝟗.𝟒𝟔% 𝐨𝐟 𝐩𝐚𝐠𝐞 𝐚𝐜𝐜𝐞𝐬𝐬𝐞𝐬 - 𝐏𝐚𝐠𝐞𝐬𝐞𝐫𝐯𝐞𝐫 𝐥𝐨𝐜𝐚𝐥 𝐍𝐕𝐌𝐞 𝐭𝐚𝐤𝐞𝐬 𝐜𝐚𝐫𝐞 𝐨𝐟 𝟎.𝟓𝟒% - 𝐀𝐧𝐝 𝐨𝐛𝐣𝐞𝐜𝐭 𝐬𝐭𝐨𝐫𝐚𝐠𝐞 𝐨𝐧𝐥𝐲 𝐝𝐢𝐝 ~𝟑𝟗 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬/𝐬 (~𝟎.𝟎𝟎𝟎𝟎𝟎𝟑𝟓%) Object storage never sits in front of a query in the lakebase architecture. Instead, reads pass through up to 3 tiers: 1. Compute keeps hot pages in a local cache (fastest tier, serving almost all reads) 2. Pageservers keep layers on local NVMe (still fast) 3. Object storage is only touched when both tiers above miss 𝐖𝐡𝐞𝐧 𝐝𝐨 𝐭𝐡𝐞 𝐩𝐚𝐠𝐞𝐬𝐞𝐫𝐯𝐞𝐫𝐬 (𝐭𝐡𝐞 𝟎.𝟓𝟒%) 𝐠𝐞𝐭 𝐢𝐧𝐯𝐨𝐥𝐯𝐞𝐝? On a local miss, compute sends GetPage@LSN to a pageserver, which returns the page as it existed at that LSN. To build it, the pageserver starts from the nearest image of the page and replays WAL records (deltas) written since. Across our us-east-1 fleet, p90 stayed under 1 delta per GetPage, meaning most requests are served straight from an image. p99 stays around 6. 𝐖𝐡𝐞𝐧 𝐝𝐨𝐞𝐬 𝐨𝐛𝐣𝐞𝐜𝐭 𝐬𝐭𝐨𝐫𝐚𝐠𝐞 𝐠𝐞𝐭 𝐢𝐧𝐯𝐨𝐥𝐯𝐞𝐝 (𝐭𝐡𝐞 ~𝟑𝟗 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬/𝐬)? Only when reads ask for data nobody has read recently. Almost always, this means branches or restores at old points in time, or projects waking up after weeks scaled to zero. And even then, only the first reads pay the latency cost. Get the full architecture breakdown: https://lnkd.in/dr-kc7dZ

"Without cheap branches, we'd have had to choose between safety and speed." When Kylon agents build apps, each workspace runs on its own Neon project, and every draft gets its own branch: https://lnkd.in/g7E7AiZ2

Managed Better Auth, Neon's auth primitive, is now an OAuth provider with MCP support built in. Turn it on to let MCP clients sign users in with your app: https://lnkd.in/gurf4HeS

Getting Stripe data into your app just got a lot easier. 𝐒𝐭𝐫𝐢𝐩𝐞 𝐃𝐚𝐭𝐚 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 now syncs subscriptions, customers, and invoices straight into Neon, in real time: https://lnkd.in/gwPxF4tB

Neon now has realtime, built by the team behind Electric. Turn any SQL query into a live query, joins and aggregates included. All inside Postgres, and ready for agents: https://lnkd.in/ehq5sWp5

Lakebase Search brings BM25 to Postgres, but BM25 can only score the terms it knows. Use our new lakebase_tokenizer extension to add custom dictionaries in plain SQL: https://lnkd.in/gBDRsnWS

Major update to our Free plan: you now get 0̶.̶5̶ ̶G̶B̶ 1 GB of Postgres storage per project, 100 projects still included. Go build.