Neon

Neon Storage is a multi-tenant key-value store with three components: Safekeepers, Pageservers, and cloud object storage (S3). Pageservers are responsible for: - Serving read requests - Acting as a cache for S3 - Processing the incoming WAL stream - Uploading data to S3

What's the responsibility of Safekeepers in Neon's architecture? Neon is Postgres with separation of storage and compute. In Neon's architecture, Safekeepers are part of the storage layer and handle durability. Instead of flushing to local disk, Postgres (compute) needs to send Write-Ahead Logs (WAL) somewhere else. That's where Safekeepers come in - they're the write buffer that ensures durability until Pageservers process and upload the incoming WAL stream to object storage. Safekeepers implement the Paxos protocol for reliability. This means the data is durable even before Pageservers finish processing it. More about Neon's architecture here: https://lnkd.in/dr-kc7dZ

The Retool platform now includes AppGen AI capabilities: you can build secure, full-stack internal tools from a prompt, directly on your own data. Backed by Neon 🤝 https://lnkd.in/g9AD7Dp9

We just launched the Neon Data API, a PostgREST-compatible REST API for Postgres, reimplemented in Rust and embedded directly into the Neon platform: https://lnkd.in/gD-pth2Q PostgREST is one of the great projects of the Postgres ecosystem. It automatically turns your schema into a REST API with RLS-based access control. But PostgREST deployments usually run one process per project: this is great for individual apps, but at Neon’s scale (with many  thousands of active databases every day) this model gets compute-heavy and fragmented. So we built a new Data API that’s leaner, multi-tenant, and built to scale across tens of thousands of databases: Rust-based → lighter CPU/memory footprint Multi-tenant → one service safely serving many databases Part of the Neon platform → Every branch has its own API endpoint Compatible with scale-to-zero → DB compute idles when not in use, while RES is always available Flexible → works with Neon Auth or any JWKS provider The Neon Data API It’s still 100% PostgREST-compatible. Migration can be as simple as pointing your client to a new endpoint and updating auth. This is not only great for developers but also for agent platforms. With the Data API, you get a backend built on serverless Postgres as the foundation, complete with auth, branching, and scale-to-zero. This is just the start: more features to come 🔥

There are a lot of good reasons to use UUIDs. Their global uniqueness comes in handy in distributed systems when data is partitioned across different databases. But otherwise, auto-increment keeps it simple! One downside of UUIDs is addressed with UUID v7 - now natively supported in Postgres 18! Previous versions like UUID v4 are completely random, which creates problems for database indexes and can significantly impact performance. v7 solves this by incorporating a timestamp, making them naturally sortable. Read more about UUID v7 and Postgres 18 here: https://lnkd.in/d7YgGDtX

Recipe to go from small startup → powering mission-critical ops for 16k+ staff: 1. PoC on Neon’s Free Plan, scale from there 2. Split reads/writes with replicas 3. Autoscale during peak traffic events 4. Branch for safe testing & updates 5. Use Retool to build dashboards fast This is exactly what DAT did. Their pipeline ingests WhatsApp/Telegram/WeChat messages → writes each one 3+ times (message, jobs, audit logs) → moves logs to blob storage. The workload: 10M txns/month of text, images, video, location, and voice notes. Full story here: https://lnkd.in/gPnyKH4d

𝐏𝐨𝐬𝐭𝐠𝐫𝐞𝐬 𝟏𝟖 𝐣𝐮𝐬𝐭 𝐬𝐡𝐢𝐩𝐩𝐞𝐝, 𝐚𝐧𝐝 𝐢𝐭’𝐬 𝐚𝐥𝐫𝐞𝐚𝐝𝐲 𝐚𝐯𝐚𝐢𝐥𝐚𝐛𝐥𝐞 𝐨𝐧 𝐍𝐞𝐨𝐧. Deploy it in a few seconds and try the new features: https://lnkd.in/g_KWi4tr

We open-sourced Elephantshark, a Ruby script that acts like a Postgres-specialized Wireshark for encrypted traffic. Works with any Postgres, not just Neon: https://lnkd.in/gzz8G3-b Wireshark is the standard tool for analyzing network traffic. The problem: most Postgres traffic is encrypted, and Wireshark can’t easily decode it. Elephantshark fills this gap by acting as a proxy between client and server, decrypting & re-encrypting TLS and logging the Postgres protocol messages.

Rolling back to previous versions is one of the most loved features in Replit and v0 by Vercel. Now you can easily build the same experience into your own agent with Neon’s new Snapshots API: https://lnkd.in/gwyr77rw When you’re building with agents, iteration is everything. Users prompt, test, tweak, and often need to go back in time to compare versions or undo a change. With code alone, rollbacks are straightforward. But for full-stack apps, the database schema and data evolve alongside the code. Without database rollbacks, reverting can leave users with broken queries, failed migrations, and mismatched data. That’s where the Snapshots API comes in:  - Powered by Neon’s copy-on-write branching - Captures both schema and data at any point in time - Restores instantly, so code + database stay perfectly in sync We’ve built a demo to show you exactly how this works: https://lnkd.in/gNSAKY8S

Postgres owes much of its success to its thriving extension ecosystem. We asked Heikki Linnakangas (long-time Postgres contributor & Neon co-founder) about his favorite extensions, and his picks align perfectly with what we see from our users. Top extensions: - pgvector - turns Postgres into a vector database (fun fact: Heikki's also a contributor). Installed in over 132k databases on Neon. - PostGIS - the true and tested OG for geospatial data. Installed in over 41k databases on Neon. Read more about the most popular Postgres extensions on Neon here: https://lnkd.in/damPD4gk