Also, Neon [0] and Aurora [1] pricing is so high that it seems to make most
use-cases impractical (well, if you want a managed offering...). Neon's top
public tier is not even what a single modern dedicated server (or virtual
machine) can provide. I would have thought decoupling compute and stor
Ah, by "shared storage" I mean that each node can acquire exclusivity, not that
they can both R/W to it at the same time.
> Some pretty well-known cases of storage / compute separation (Aurora, Neon)
> also share the storage between instances,
That model is cool, but I think it's more of a solu
Sorry, I was referring to this:
> But when PostgreSQL instances share storage rather than replicate:
> - Consistency seems maintained (same data)
> - Availability seems maintained (client can always promote an accessible
node)
> - Partitions between PostgreSQL nodes don't prevent the system from
What you describe doesn’t look like something very useful for the vast majority
of projects that needs a database. Why would you even want that if you can
avoid it?
If your “single node” can handle tens / hundreds of thousands requests per
second, still have very durable and highly available s
A shared storage would require a lot of extra work. That's essentially what
AWS Aurora does.
You will have to have functionality to sync in-memory states between nodes,
because all the instances will have cached data that can easily become
stale on any write operation.
That alone is not that simple
And finally, some read only benchmarks with the same postgres build.
9P:
postgres@zerofs:/mnt_9p$ pgbench -vvv -c 100 -j 40 -t 1 bench -S
pgbench (16.9 (Ubuntu 16.10-1))
starting vacuum...end.
starting vacuum pgbench_accounts...end.
transaction type:
scaling factor: 50
query mode: simple
num
I built postgres (same version, 16.9) but --with-block-size=32 (I'd really love
if this would be a initdb time flag!) and did some more testing:
synchronous_commit = off
postgres@zerofs:~$ pgbench -vvv -c 100 -j 40 -t 1 bench
pgbench (16.9 (Ubuntu 16.10-1))
starting vacuum...end.
starting va
Hi,
I went ahead and did that test.
Here is the postgresql config I used for reference (note the wal options
(recycle, init_zero) as well as full_page_writes = off, because ZeroFS cannot
have torn writes by design).
https://gist.github.com/Barre/8d68f0d00446389998a31f4e60f3276d
Test was runni
> This then begs the obvious question of how fast is this with
> synchronous_commit = on?
Probably not awful, especially with commit_delay.
I'll try that and report back.
Best,
Pierre
On Fri, Jul 25, 2025, at 00:03, Jeff Ross wrote:
> On 7/24/25 13:50, Pierre Barre wrote:
>
>> It’s not “safe”
Hi Marco,
Thanks for the kind words!
> and potentially elaborate on other projects for an active/active cluster! I
> applaud you.
I wrote an argument there:
https://github.com/Barre/ZeroFS?tab=readme-ov-file#cap-theorem
I definitely want to write a proof of concept when I get some time.
Best
My humble take on this project: well done! You are opening the doors to
work on a much-needed endeavor, decouple compute from storage, and
potentially elaborate on other projects for an active/active cluster! I
applaud you.
On Thu, Jul 17, 2025, 4:59 PM Pierre Barre wrote:
> Hi everyone,
>
> I w
On 7/24/25 13:50, Pierre Barre wrote:
It’s not “safe” or “unsafe”, there’s mountains of valid workloads which don’t
require synchronous_commit. Synchronous_commit don’t make your system
automatically safe either, and if that’s a requirement, there’s many
workarounds, as you suggested, it cert
It’s not “safe” or “unsafe”, there’s mountains of valid workloads which don’t
require synchronous_commit. Synchronous_commit don’t make your system
automatically safe either, and if that’s a requirement, there’s many
workarounds, as you suggested, it certainly doesn’t make the setup useless.
Be
On Fri, Jul 18, 2025 at 12:57:39PM +0200, Pierre Barre wrote:
> - Postgres configured accordingly memory-wise as well as with
> synchronous_commit = off, wal_init_zero = off and wal_recycle = off.
Bingo. That's why it's fast (synchronous_commit = off). It's also why
it's not safe _unless_ you
On Fri, Jul 18, 2025 at 06:40:58AM +0200, Laurenz Albe wrote:
> On Fri, 2025-07-18 at 00:57 +0200, Pierre Barre wrote:
> > Looking forward to your feedback and questions!
>
> I think the biggest hurdle you will have to overcome is to
> convince notoriously paranoid DBAs that this tall stack
> prov
> "NFS" is a key word that does not inspire confidence in
PostgreSQL circles...
Coming back to this, I just implemented 9P, which should translates to proper
semantics for FSYNC.
mount -t 9p -o trans=tcp,port=5564,version=9p2000.L,msize=65536,access=user
127.0.0.1 /mnt/9p
Best,
Pierre
On Fri,
> The interesting thing is, a few searches about the performance return mostly
> negative impressions about their object storage in comparison to the original
> S3.
I think they had a rough start, but it's quite good now from what I've
experienced. It's also dirt-cheap, and they don't bill for
Thanks, I learned something else: I didn't know Hetzner offered S3
compatible storage.
The interesting thing is, a few searches about the performance return
mostly negative impressions about their object storage in comparison to the
original S3.
Finding out what kind of performance your benchmark
Now, I'm trying to understand how CAP theorem applies here. Traditional
PostgreSQL replication has clear CAP trade-offs - you choose between
consistency and availability during partitions.
But when PostgreSQL instances share storage rather than replicate:
- Consistency seems maintained (same dat
Hi Seref,
For the benchmarks, I used Hetzner's cloud service with the following setup:
- A Hetzner s3 bucket in the FSN1 region
- A virtual machine of type ccx63 48 vCPU 192 GB memory
- 3 ZeroFS nbd devices (same s3 bucket)
- A ZFS stripped pool with the 3 devices
- 200GB zfs L2ARC
- Postgres con
Sorry, this was meant to go to the whole group:
Very interesting!. Great work. Can you clarify how exactly you're running
postgres in your tests? A specific AWS service? What's the test
infrastructure that sits above the file system?
On Thu, Jul 17, 2025 at 11:59 PM Pierre Barre wrote:
> Hi eve
Hi Laurenz,
> I think the biggest hurdle you will have to overcome is to
> convince notoriously paranoid DBAs that this tall stack
> provides reliable service, honors fsync() etc.
Indeed, but that doesn't have to be "sudden." I think we need to gain
confidence in the whole system gradually by st
On Fri, 2025-07-18 at 00:57 +0200, Pierre Barre wrote:
> Looking forward to your feedback and questions!
I think the biggest hurdle you will have to overcome is to
convince notoriously paranoid DBAs that this tall stack
provides reliable service, honors fsync() etc.
Performance is great, but it i
Hi everyone,
I wanted to share a project I've been working on that enables PostgreSQL to run
on S3 storage while maintaining performance comparable to local NVMe. The
approach uses block-level access rather than trying to map filesystem
operations to S3 objects.
ZeroFS: https://github.com/Barr
24 matches
Mail list logo
