Fdb emulator 2 by jubrad · Pull Request #36464 · MaterializeInc/materialize

jubrad · 2026-05-08T01:06:43Z

Add FoundationDB as an alternative metadata store for the emulator image. Both PostgreSQL and FoundationDB are installed in the base image. The entrypoint reads MZ_METADATA_STORE (default: postgres) to select which backend to start. Set MZ_METADATA_STORE=foundationdb to use FDB.

in this case we'll publish a -fdb materialize emulator image for every image ex:
materialize/materialized:26.25.0-fdb

revival of #35087

Install FoundationDB client and server alongside PostgreSQL in the emulator base image. The entrypoint script now reads MZ_METADATA_STORE (defaulting to "postgres") to select which backend to start and which URLs to configure. Set MZ_METADATA_STORE=foundationdb to use FDB. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Use `foundationdb:?prefix=X` instead of embedding the cluster file path and legacy `options` parameter. Export FDB_CLUSTER_FILE so the FDB client discovers the cluster via the environment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Avoid penalizing postgres-only users with the ~100 MB FoundationDB packages. The postgres image (materialized) no longer includes FDB, and a new materialized-fdb image provides the FDB-backed variant. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Replace directory symlink with individual file symlinks, since mzbuild cannot traverse a symlinked directory. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

materialized-base and materialized-fdb-base duplicated ~40 lines of shared setup (user creation, apt packages, console, nginx config) and the console version had already drifted (26.14.0-dev.0 vs 26.13.0-dev.0). Extract the common parts into materialized-common-base so both backend-specific bases extend it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add publish-as/tag-suffix support to mzbuild so the FDB emulator image is published under the same Docker image name as the postgres variant but with a -fdb tag suffix (e.g. materialize/materialized:latest-fdb, materialize/materialized:v26.23.0-fdb). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Docker COPY cannot follow symlinks that point outside the build context. Replace the entrypoint.sh and listener_configs symlinks with mzbuild copy pre-image steps that copy the files from ci/ at build time. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

antiguru

Makes sense, but I think you need a review from @def- here!

antiguru · 2026-05-08T20:07:43Z

+publish-as: materialized
+tag-suffix: -fdb
+pre-image:
+  - type: cargo-build


Does this work?

Everything builds and the image seems to work

def-

I assume this still makes our docker images for the emulator significantly larger for an experiment. What is the goal? Edit: I see, so we use a -fdb version suffix, that's fine then. But it does make the build a bit slower
Based on https://buildkite.com/materialize/test/builds/122662 we seem to be still pushing materialized-fdb:

materialize/materialized-fdb-base:mzbuild-CEVVAAJFWG4OCU3BJ7F6PZALKAB477RU
materialize/materialized-fdb:mzbuild-3OCYPBBDFDNOF2H77HQGG4V7L7TEJ6HX

jubrad · 2026-05-09T16:15:26Z

I assume this still makes our docker images for the emulator significantly larger for an experiment. What is the goal? Edit: I see, so we use a -fdb version suffix, that's fine then. But it does make the build a bit slower

Why would it? we shouldn't be packaging FDB in our postgres based emulator so it shouldn't change the size.

What is the goal?

My suspision is that this will actually make the emulator more resource efficient, especially for larger local testing with a lot of sources or low tic intervals. It seems like it lowers CPU a decent amount on some local demos where I'm setting a very low tic interval.

Based on https://buildkite.com/materialize/test/builds/122662 we seem to be still pushing materialized-fdb

@def- wait... I don't see us pushing this to dockerhub?
https://hub.docker.com/u/materialize?page=1&search=materialized

I think we're just using materialize-fdb as an internal name.


$ docker manifest create --amend materialize/materialized:v26.24.0-dev.0--pr.g9a5b17bdaa0f69293815c6b6d2531b38bef6ba80-fdb materialize/materialized-fdb:mzbuild-3OCYPBBDFDNOF2H77HQGG4V7L7TEJ6HX materialize/materialized-fdb:mzbuild-X7VXA2N6HLSO5W5NBP5UZD45WEQ67L3T
--
Created manifest list docker.io/materialize/materialized:v26.24.0-dev.0--pr.g9a5b17bdaa0f69293815c6b6d2531b38bef6ba80-fdb
$ docker manifest push materialize/materialized:v26.24.0-dev.0--pr.g9a5b17bdaa0f69293815c6b6d2531b38bef6ba80-fdb
Pushed ref docker.io/materialize/materialized@sha256:dd79ad5d44adf6d5ce6d45039f4284f4a47da9e8583aa7225e70f4c85b43f820 with digest: sha256:dd79ad5d44adf6d5ce6d45039f4284f4a47da9e8583aa7225e70f4c85b43f820
Pushed ref docker.io/materialize/materialized@sha256:2f2e58db5de1984af3b89269cf7349c9c9309c1b7af7628bfd0924c0b29b6a50 with digest: sha256:2f2e58db5de1984af3b89269cf7349c9c9309c1b7af7628bfd0924c0b29b6a50
sha256:b9a8064ab878d42e299d65002e90be143295c2482c2a6c9d97e56041f6dfdc1f

def-

Thanks, lgtm for some experiments. I think long term we should decide what to use for emulator and stick with it. When I ran my experiments I saw lower CPU usage with postgres compared to fdb fwiw. I'm mostly afraid that we stay in this state and have to push two versions out for months or even years.

def- · 2026-05-12T02:28:27Z

            name += f":{tag}"
        return name

+    def publish_docker_name(self, tag: str | None = None) -> str:


I'm not super happy with this whole logic, and translating between materialized-fdb and materialized:...-fdb. Why don't we just build it as materialized-fdb directly instead of having this translation layer?

publish_multiarch_images iterates all images in the dependency set including non-publishable base images. Skip images with publish=false to avoid trying to create manifests for images that were never pushed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

antiguru and others added 6 commits May 7, 2026 20:25

emulator: fix FoundationDB URL format

b94c1b0

Use `foundationdb:?prefix=X` instead of embedding the cluster file path and legacy `options` parameter. Export FDB_CLUSTER_FILE so the FDB client discovers the cluster via the environment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

emulator: fix materialized-fdb listener_configs for mzbuild

6128d6a

Replace directory symlink with individual file symlinks, since mzbuild cannot traverse a symlinked directory. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

jubrad force-pushed the fdb_emulator_2 branch 2 times, most recently from 92cbe30 to 9d94e76 Compare May 8, 2026 01:43

jubrad force-pushed the fdb_emulator_2 branch from 9d94e76 to f2cc9ec Compare May 8, 2026 13:56

jubrad requested review from antiguru and def- May 8, 2026 20:05

antiguru reviewed May 8, 2026

View reviewed changes

def- reviewed May 9, 2026

View reviewed changes

jubrad marked this pull request as ready for review May 9, 2026 16:32

jubrad requested a review from def- May 11, 2026 20:33

def- approved these changes May 12, 2026

View reviewed changes

jubrad force-pushed the fdb_emulator_2 branch from 9a5b17b to c1bc1a6 Compare May 15, 2026 13:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fdb emulator 2#36464

Fdb emulator 2#36464
jubrad wants to merge 8 commits into
MaterializeInc:mainfrom
jubrad:fdb_emulator_2

jubrad commented May 8, 2026 •

edited

Loading

Uh oh!

antiguru left a comment

Uh oh!

antiguru May 8, 2026

Uh oh!

jubrad May 8, 2026

Uh oh!

def- left a comment •

edited

Loading

Uh oh!

jubrad commented May 9, 2026 •

edited

Loading

Uh oh!

def- left a comment

Uh oh!

def- May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

jubrad commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antiguru left a comment

Choose a reason for hiding this comment

Uh oh!

antiguru May 8, 2026

Choose a reason for hiding this comment

Uh oh!

jubrad May 8, 2026

Choose a reason for hiding this comment

Uh oh!

def- left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jubrad commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

def- left a comment

Choose a reason for hiding this comment

Uh oh!

def- May 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jubrad commented May 8, 2026 •

edited

Loading

def- left a comment •

edited

Loading

jubrad commented May 9, 2026 •

edited

Loading