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-…
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-…
9
30
173
32,486
Reynold Xin retweeted
I don't think we should fight. The two companies are complementary. Since you're not doing this AI stuff, I really think Snowflake should consider getting its AI tokens through Databricks. You can get both cheap OSS models as well as frontier (OAI/Ant/Gemini/Grok) models from our platform. It all goes through Unity Gateway which has Smart Routing, Budgets, and Access Control. You can even use Omnigent with any harness, including CoCo. Most of our customers used this to reduce token spend ~30% last few months while token count went up. Genie lets you then track, control, manage that spend, all your financials, marketing, etc. Quick POC?
137
173
2,612
639,112
Reynold Xin retweeted
We’ve raised an oversubscribed $30M Series A1 led by @walden_catalyst to build the Global Compute Grid.
We’re turning fragmented GPU capacity into one unified platform where AI teams can access, manage, sell, and orchestrate compute.
Our mission: make the world’s compute liquid.
We’re turning fragmented GPU capacity into one unified platform where AI teams can access, manage, sell, and orchestrate compute.
Our mission: make the world’s compute liquid.
41
32
275
67,929
No wonder Apple is a 5 trillion dollar company.
UPS delivery guy: "Are you waiting by the door for this?"
me: "Yes!"
him: "I never run into people when I deliver, but on iPhone release date, everybody is home waiting."
UPS delivery guy: "Are you waiting by the door for this?"
me: "Yes!"
him: "I never run into people when I deliver, but on iPhone release date, everybody is home waiting."
4
2
45
4,143
Reynold Xin retweeted
Postgres 19 is late. @robertmhaas, one of the Postgres committers on our team, explains why: LLMs are finding bugs faster than they can be fixed, including in older releases, and that extra work eats into v19 review time
neon.com/blog/postgres-…
neon.com/blog/postgres-…
4
7
42
3,986
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.
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
251
420
37,591
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-…
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-…
5
4
31
4,386
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.
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
65
6,788
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 n, 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,528
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 yo. Now you can run system one decisions on all your big data, see screenshot.
databricks.com/blog/introduci…
We just dropped 𝚊𝚒_𝚍𝚎𝚌𝚒𝚍𝚎(), which runs decision models natively on all yo. Now you can run system one decisions on all your big data, see screenshot.
databricks.com/blog/introduci…
22
71
320
26,199
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-a…
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-a…
4
10
69
7,192
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!
Databricks inference is moving super fast!
6
11
113
11,680
Reynold Xin retweeted
The results for AI Gateway Latency benchmarks are in. Here is one for @Kimi_Moonshot.
🥇@neondatabase
🥈@BlazeRail_AI
🥉@ngrokHQ
🥇@neondatabase
🥈@BlazeRail_AI
🥉@ngrokHQ
1
4
13
3,287
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.
Starting with: Lakebase Postgres, Object Storage, Functions, Managed Better Auth, and AI Gateway. More to come.
23
21
134
28,308
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 querPostgres
• 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 🐘
• Every keystroke is a live querPostgres
• 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
56,039
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,561
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 base 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.
0
1
36
6,032