Replacing EBS and Rethinking Postgres Storage from First Principles

Posted by mfreed 10/29/2025

Replacing EBS and Rethinking Postgres Storage from First Principles(www.tigerdata.com)

105 points | 59 commentspage 2

otterley 10/31/2025|

I’m a bit confused about this:

“The storage device driver exposes Fluid Storage volumes as standard Linux block devices mountable with filesystems such as ext4 or xfs. It...allows volumes to be resized dynamically while online.”

Yet an xfs file system cannot be shrunk at all, and an ext4 filesystem cannot be shrunk without first unmounting it.

Are you simply doing thin provisioning of these volumes, so they appear to be massive but aren’t really? I see later that you say you account for storage based on actual consumption.

namibj 10/31/2025|

..... They are block devices. Those allow resizing.

They can be used with, for example, the listed file systems.

No one claimed the listed file systems would (usefully) cooperate with (all aspects of) the block device's resizing.

otterley 10/31/2025||

You can’t just shrink a block device any way you want. It has to be done in concert with the filesystem on top of it to ensure any allocated blocks in the space to be deallocated are relocated to a safe area in the volume. Otherwise, data could be lost and filesystem corruption could occur.

Put differently, there is no point in being able to shrink a volume if you can’t safely shrink the filesystem that uses it.

The usual solution to this problem is thin provisioning, where you put a translation layer between the blocks the filesystem thinks it’s using and the actual underlying blocks. With thin provisioning you can allocate only, say, 1GB to the physical storage, but the block device presents itself as much larger than that, so you can pretend to create a 1PB filesystem on top of it.

thr0w 10/30/2025||

Postgres for agents, of course! It makes too much sense.

akulkarni 10/30/2025||

Thanks! We agree :-)

We just launched a bunch around “Postgres for Agents” [0]:

forkable databases, an MCP server for Postgres (with semantic + full-text search over the PG docs), a new BM25 text search extension (pg_textsearch), pgvectorscale updates, and a free tier.

[0] https://www.tigerdata.com/blog/postgres-for-agents

jacobsenscott 10/30/2025|||

The agent stuff is BS for the pointy hairs. This seems to address real problems I've had with PG though.

akulkarni 10/30/2025||

Yeah, I know what you mean. I used to roll my eyes every time someone said “agentic,” too. But after using Claude Code myself, and seeing how our best engineers build with it, I changed my mind. Agents aren’t hype, they’re genuinely useful, make us more productive, and honestly, fun to work with. I’ve learned to approach this with curiosity rather than skepticism.

xpe 10/31/2025||

Hard to say if the above comment is serious or sarcastic.

To my eye, seeing "Agentic Postgres" at the top of the page, in yellow, is not persuasive; it comes across as bandwagony. (About me: I try to be open but critical about new tech developments; I try out various agentic tooling often.).

But I'm not dismissing the product. I'm just saying this part is what I found persuasive:

> Agents spin up environments, test code, and evolve systems continuously. They need storage that can do the same: forking, scaling, and provisioning instantly, without manual work or waste.

That explains it clearly in my opinion.

* Seems to me, there are taglines that only work after someone in "on-board". I think "Agentic Postgres" is that kind of tagline. I don't have a better suggestion in mind at the moment, though, sorry.

tayo42 10/30/2025||

Are they not using aws anymore? I found that confusing. It says they're not using ebs, not using attached nvme, but I didn't think there were other options in aws?

mfreed 10/30/2025||

Tiger Cloud certainly continues to run on AWS. We have built it to rely on fairly low-level AWS primitives like EC2, EBS, and S3 (as opposed to some of the higher-level service offerings).

Our existing Postgres fleet, which uses EBS for storage, still serves thousands of customers today; nothing has changed there.

What’s new is Fluid Storage, our disaggregated storage layer that currently powers the new free tier (while in beta). In this architecture, the compute nodes running Postgres still access block storage over the network. But instead of that being AWS EBS, it’s our own distributed storage system.

From a hardware standpoint, the servers that make up the Fluid Storage layer are standard EC2 instances with fast local disks.

wrs 10/30/2025||

There weren’t, so they built one. (It is NVMe at the bottom, though.)

runako 10/30/2025||

Thanks for the writeup.

I'm curious whether you evaluated solutions like zfs/Gluster? Also curious whether you looked at Oracle Cloud given their faster block storage?

kristianp 10/30/2025||

So they've built a competitor to EBS that runs on EC2 and nvme. Seems like their prices will need to be much higher than those of AWS to get decent profit margins. I really hate being in the high-cost ecosystem of the large cloud providers, so I wouldn't make use of this.

cpt100 10/29/2025|

pretty cool