Feedback-ID: i97614980:Fastmail
MIME-Version: 1.0
Date: Wed, 08 Apr 2026 22:50:54 +0200
From: "Pierre Barre" <pierre@barre.sh>
To: pgsql-general@lists.postgresql.org
Message-Id: <bd776a00-2fc1-48c0-8639-0ab8e51d775a@app.fastmail.com>
In-Reply-To: <dd5254f2-a308-4520-888e-e4f49a81a6ed@app.fastmail.com>
References: <a9fe5ddb-9685-4139-bc1f-88161a7a4da3@app.fastmail.com>
 <CAG1bHGOzCNtDeW0W8gRO7mpW=t7BqWh-iz4kX5VRCPgt_6Tr6Q@mail.gmail.com>
 <8188513c-e089-4273-b2be-16dd0a5a0a80@app.fastmail.com>
 <aIKNLuEis1DQEOGv@ubby>
 <5c512367-0f67-4bcc-9897-1acf9c0f8bd3@app.fastmail.com>
 <60027457-1b85-4a69-a67e-ee87f7cabd61@openvistas.net>
 <dd5254f2-a308-4520-888e-e4f49a81a6ed@app.fastmail.com>
Subject: Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/bd776a00-2fc1-48c0-8639-0ab8e51d775a%40app.fastmail.com>
Precedence: bulk

Hi all,

Building on that, I made Postgres run in the browser using a x86 JavaScr=
ipt emulator, with ZeroFS mounted in that vm through vsock-virtio that c=
hannels back to a 9P websocket wrapper: https://www.zerofs.net/postgresq=
l-in-the-browser

Best,
Pierre

On Mon, Feb 16, 2026, at 12:06, Pierre Barre wrote:
> Hi all,
>
> Circling back on this thread, ZeroFS now supports placing its WAL on=20
> local storage (or something like S3 Express One Zone). ZeroFS wal is=20
> sub-gigabyte and just there to handle frequent syncs, it doesn't act a=
s=20
> writeback caching.
>
> Here are pgbench results with synchronous_commit =3D on, WAL on local=20
> NVMe, on a 6-core / 32GB RAM machine with a 4 Gb/s pipe:
>
> $ pgbench -c 100 -T 100 --protocol=3Dprepared
>
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 100
> query mode: prepared
> number of clients: 100
> number of threads: 1
> duration: 100 s
> number of transactions actually processed: 1,578,675
> number of failed transactions: 0 (0.000%)
> latency average =3D 6.312 ms
> tps =3D 15,843 (without initial connection time)
>
> Best,
> Pierre
>
> On Fri, Jul 25, 2025, at 00:03, Jeff Ross wrote:
>> On 7/24/25 13:50, Pierre Barre wrote:
>>
>>> It=E2=80=99s not =E2=80=9Csafe=E2=80=9D or =E2=80=9Cunsafe=E2=80=9D,=
 there=E2=80=99s mountains of valid workloads which don=E2=80=99t requir=
e synchronous_commit. Synchronous_commit don=E2=80=99t make your system =
automatically safe either, and if that=E2=80=99s a requirement, there=E2=
=80=99s many workarounds, as you suggested, it certainly doesn=E2=80=99t=
 make the setup useless.
>>>
>>> Best,
>>> Pierre
>>>
>>> On Thu, Jul 24, 2025, at 21:44, Nico Williams wrote:
>>>> On Fri, Jul 18, 2025 at 12:57:39PM +0200, Pierre Barre wrote:
>>>>> - Postgres configured accordingly memory-wise as well as with
>>>>>    synchronous_commit =3D off, wal_init_zero =3D off and wal_recyc=
le =3D off.
>>>> Bingo.  That's why it's fast (synchronous_commit =3D off).  It's al=
so why
>>>> it's not safe _unless_ you have a local, fast, persistent ZIL device
>>>> (which I assume you don't).
>>>>
>>>> Nico
>>>> --
>> This then begs the obvious question of how fast is this with=20
>> synchronous_commit =3D on?