Pinned Tweet
I find the Lakebase design for serverless Postgres very elegant, so I spent some time explaining how it works in this blog.
The blog starts by explaining how databases really persist data (with a write-ahead-log and data files that are updated async), and how Lakebase separates storage and compute by externalizing those two components. It ends with how the Lakebase architecture naturally leads to LTAP, enabling OLTP and analytical workloads against a single governed copy of data.
My goal was to make it readable by anyone curious about how these systems work, not just database and storage experts. That turned out to be a lot more challenging than I first thought. Database storage is one of the most complex areas in computer science (the ARIES paper cited in blog was the hardest paper I personally ever had to read). The first draft had too little detail and I couldn't land the ideas. The second had too much and I'd lost anyone who isn't already a storage expert. This is the third draft, and I'd love feedback on whether the depth feels right.
databricks.com/blog/lakebase…
7
30
172
32,238
Reynold Xin retweeted
Can a single database architecture satisfy both vibe-coded and large scale enterprise apps?
The same approach makes small database ultra cheap to run and branch can also make a large one faster and easier to operate. We call this architecture Lakebase.
10
241
391
18,173
Reynold Xin retweeted
Any SQL query, reactively kept up to date on front end.
And is so so simple to use, even and agent can do it!
--
Six years ago I was building an app, and thought "wouldn't it be so much easer if we could just subscribe to a query on the front end".
That started my journey through Local First, lead to joining @ElectricSQL, where we built multiple Sync Engines, PGlite and @tan_stack DB.
We finally achieved that goal with @neondatabase Realtime.
Perfect thing for a side project, give it a go!
neon.com/blog/neon-now-has-r…
5
4
32
4,228
Built by the Electric team (who also did pglite, i.e. Postgres on WASM), Neon Realtime is an incremental query engine to make it dramatically easier to build apps that sync data in realtime.
It leverages the Lakebase architecture's separation of storage and compute to run on a separate compute instance. This avoids overwhelming the primary write Postgres instance and pushes the write operations incrementally to all the subscribers.
Check it out. You can now build complex realtime sync apps in just a few lines of code. This is a great example of how hardcore database technologies can make the app developers' lives much simpler.
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.
It’s in public beta and available in all Neon plans. Give it a try and tell us what you think!
6
8
63
6,628
Super excited to welcome the Responsive team to @Databricks/@neondatabase to help take Lakebase Postgres to the next level. The best database is a lakebase!
I’m excited to announce that Responsive has been acquired by Databricks to accelerate the development of Lakebase and Neon!
We couldn't be more excited to join the Lakebase team. We've long admired their technical vision, and the more we got to know them, the more impressed we became by their ambition, execution, and momentum. It feels like a natural home for us.
I want to thank Responsive’s customers, investors, and especially the team. More than anything, I’m grateful for the trust you’ve placed in us through the good times and the tough times.
Onward and upward!
2
5
53
3,455
Reynold Xin retweeted
Everyone has been obsessed by Jev and what it can do, and they should be! Fast typed decisions >> slow text generation. It's a complete game changer. But how do you do that with all the data you have?
We just dropped 𝚊𝚒_𝚍𝚎𝚌𝚒𝚍𝚎(), which runs decision models natively on all your data in @databricks . Now you can run system one decisions on all your big data, see screenshot.
databricks.com/blog/introduc…
20
70
310
21,227
Excited to announce our new partnership with @DecagonAI to bring richer enterprise data intelligence directly into customer conversations.
AI agents are only as useful as the context they can access.
Enterprises already have an incredibly rich record of their customers in Databricks. Orders, payments, product usage, preferences, and countless other signals all help explain who a customer is and what they need.
Through this partnership, Decagon agents can access governed data from the Databricks when they need it, while insights from those conversations can flow back into Databricks and become useful across the rest of the business.
We’re excited to work with the Decagon team to make enterprise customer agents more context aware while keeping data governance at the center.
decagon.ai/blog/decagon-and-…
4
10
70
7,093
Reynold Xin retweeted
We’re bringing Databricks Unity Gateway to developers on Neon (@neondatabase), and it’s the fastest AI Gateway for Kimi K3!
Databricks inference is moving super fast!
6
11
113
11,585
Reynold Xin retweeted
The results for AI Gateway Latency benchmarks are in. Here is one for @kimi_moonshot.
🥇@neondatabase
🥈@blazerail_ai
🥉@ngrokhq
1
4
13
3,216
Reynold Xin retweeted
The Neon backend is GA. A complete set of primitives for apps and agents built around the database, with open standards, no lock-in, and branching-first by design.
Starting with: Lakebase Postgres, Object Storage, Functions, Managed Better Auth, and AI Gateway. More to come.
23
22
136
28,233
Reynold Xin retweeted
Built a full-text search over all of Hacker News (~49M stories, comments, jobs & polls, syncing live per hour) to be 𝐬𝐮𝐫𝐩𝐫𝐢𝐬𝐢𝐧𝐠𝐥𝐲 𝐟𝐚𝐬𝐭 with no Next.js level cache and all magic at the Neon Postgres layer: hnfaster.vercel.app 🎉
• Every keystroke is a live query against @neondatabase Postgres
• BM25 (powered by Lakebase Search) ranking runs inside the Postgres
• No connection pool, just SQL-over-HTTP round trips
• pg_prewarm loads the table + every index into cache
• partial BM25 index per type, predicate matching the WHERE clause
• Deployed on @vercel
Just Postgres doing Postgres things, close to the compute 🐘
18
11
203
55,989
The best database for agents and recommended by agents is Lakebase Postgres on neon.com/
#1 in Claude Code, Codex and Cursor. Still first for GPT-6 Astra and Fable 5.1
@neondatabase ripped our leaderboard of which database agents choose.
Agents cite easy setup, branching and lower compute bills through scale-to-zero.
Every run open 👇
armature.tech/leaderboards#a…
4
13
87
13,516
Pretty good summary!
Sunday morning reading - a @VLDBconf 2026 paper on Lakebase from Databricks .. a very nice overview of the architecture that belongs to the same family as any system that treats object storage as the durable backplane and puts a low-latency cache/log in front of it.
Here are some points on how Lakebase handles durability and failure handling, things that differ so subtly across similar platforms like Aurora ..
• Commit point. Lakebase does not fsync WAL on the Postgres compute node. COMMIT returns when a quorum of safekeepers - typically two of three, in different AZs - has flushed that WAL record to local disk. Pageservers and object storage are not in that handshake.
• What each layer is allowed to lose. Compute can vanish at any time, it holds no durable state. A pageserver is a cache, so losing its NVMe does not drop committed transactions. Durability of recent writes sits on safekeeper disks until those segments are uploaded to object storage.
• The tail window. After SUCCESS, new WAL exists only on the safekeeper quorum. S3 catches up later, tracked by backup LSN. If a quorum of those flushed SK copies is destroyed before that upload, acknowledged writes are gone. That is the window, it is not closed at commit time.
• Compute and pageserver failure. Compute crash, scale-to-zero, and failover are 0 data loss because a new compute attaches to the same log. Pageserver NVMe loss does not drop committed transactions, another pageserver can reconstruct pages from WAL and from layers already in object storage.
• Object storage as the long-term copy, not the commit copy. Once backup LSN has passed a segment, Safekeeper-local WAL can be dropped and history lives in the lake. Branching and Point in time recovery use that LSN-addressable history. They do not move the commit rule: SUCCESS still means quorum disk flush, not an S3 PUT.
1
36
6,005
Reynold Xin retweeted
Lakebaseの論文がVLDBで公開されている！AuroraやAlloyDBは第2世代で、オブジェクトストレージ上にオープンな形式でデータを保存するLakebaseは第3世代ということらしいよ。
vldb.org/pvldb/vol19/p4385-p…
2
17
100
12,839
Reynold Xin retweeted
#VLDB2026 is underway, and Databricks is here as a Gold Sponsor.
We’re sharing what we’re building for the future of agent-native data infrastructure, including:
• a keynote from Databricks co-founder @rxin on why the agentic future demands Lakebase Postgres
• AutoLiquid and Ultron query optimization
• Lakehouse//RT, Lakebase, and LTAP
• conversations with the database community on the ground
Still ahead: sessions and demos on Lakebase, @ApacheSpark Structured Streaming, and Enzyme.
If you’re at VLDB, come find the team 👋
3
8
50
5,865
Reynold Xin retweeted
Postgres on S3 is the right design, but even more interesting is making WAL the source of truth. This is how our storage works - we wrote a deep dive, summary on thread: neon.com/blog/wal-s3-lakebas…
12
27
327
114,219
Reynold Xin retweeted
This is true. It wasn't actually possible before 2010 because datacenter networks would bottleneck. We used to design coupled storage/compute where you brought compute close to "big data". But research on "full bisection bandwidth" networks made it possible to essentially just talk from any machine to the storage system at full speed. The disaggregation started then! Databricks and Snowflake started soon after many others followed. Now "Put it on the object store" is the way to go.
"Put it on the object store" remains undefeated.
- OLAP: Lakehouse
- OLTP: Lakebase
- Kafka: Warpstream
- Vector Search: Turbopuffer
- Git: Cursor Origin
9
27
341
46,743
Reynold Xin retweeted
Today, we announced that we crossed $7B in revenue run-rate, growing over 80% year over year in Q2.
We also shared:
🚀 $100M+ revenue run-rate for Lakebase
🚀 $1.5B+ revenue run-rate for Lakehouse, growing over 100% year over year
🚀 Continued positive adjusted free cash flow
And we raised $5B in our latest fundraise.
We’ll use this capital to invest in:
1️⃣ Lakebase, our serverless Postgres database built for AI agents
2️⃣ Genie, our AI coworkers that actually understand your business data
3️⃣ Unity AI Gateway, our multi-AI governance solution that helps control costs
@iamVictorDey shares more in @Forbes:
forbes.com/sites/victordey/2…
77
243
1,018
312,349