PostgreSQL 18 wire-compatible server on SQLite (Zig)

Implement a Zig program that stands in for PostgreSQL 18's server-side executables, using SQLite as the underlying storage engine.

The verifier baseline is pinned to PostgreSQL 18.4.

After your run ends, the verifier runs PostgreSQL's own regression suite and cluster-lifecycle tests against your implementation.

Required compatibility:

• A PostgreSQL 18 client must not be able to tell that it is talking to anything other than a real PostgreSQL 18 instance.
• If a normal client, driver, ORM, migration tool, or test harness can detect that your server is not PostgreSQL 18 through the public API surface it uses, that is a failure in spirit.

Setup

1. Your Zig workspace is /app/postgres-sqlite.
2. PostgreSQL 18 documentation is available offline at /reference/postgresql-docs/ (start at index.html; w3m is installed).
3. PostgreSQL's psql client (18.4) is installed.
4. A visible test battery lives at /app/tests_dev/ — see "Scoring" below.

Deliverable

A buildable Zig project in /app/postgres-sqlite.

Build is driven by /app/postgres-sqlite/build.sh, which must use zig build-exe directly — do not rely on zig build inside the container. If you need extra compile or link flags, put them in build.sh so the visible tests and the verifier build exactly the same way.

• visible tests build with: bash ./build.sh -Doptimize=ReleaseSafe
• the verifier builds with: bash ./build.sh -Doptimize=ReleaseFast

The verifier then locates your executable under zig-out/bin/ and uses it as a multi-call executable, symlinking it to PostgreSQL server utility names:

• postgres
• initdb
• pg_ctl

Design your program to dispatch on argv[0] (or an equivalent mechanism) so all three entry points work from one binary.

Hidden verification

The verifier receives PostgreSQL 18.4 regression tests and cluster-lifecycle tests that you cannot access during the run. It will:

1. Reconstruct a PostgreSQL 18.4-style test harness from the hidden test bundle and packaged PostgreSQL 18.4 support files.
2. Use packaged PostgreSQL 18.4 binaries for the client/admin tools (psql, etc.) and build hidden support artifacts as needed.
3. Replace the server-side entrypoints with your binary.
4. Run the regression suite — each test is a .sql script fed to psql -X -a -q -d <db> -v HIDE_TABLEAM=on -v HIDE_TOAST_COMPRESSION=on, whose output is compared against PostgreSQL's own expected output.
5. Run cluster-lifecycle tests, which create temporary clusters using your initdb, pg_ctl, and postgres compatibility surface.

Your score is the combined pass rate across those hidden tests.

Scoring

Your score is the pass rate over a pooled set of graded units from three layers:

score = (compat_passed + regression_files_passed + tap_files_passed)
        ───────────────────────────────────────────────────────────
        (all compat checks + all regression files + all TAP files)

• compat — many small, individual wire-compatibility checks (does SELECT 1 return 1, does SHOW server_version work, does a bad query raise the right SQLSTATE, …). Each is one graded unit. These are the easiest points and the first thing to make work.
• regression — PostgreSQL 18.4's own regression test scripts, counted per file: a whole .sql feature area counts only if its entire output matches PostgreSQL's expected output. Getting most of a file right earns nothing on this layer — you must make an entire feature area behave exactly like PostgreSQL.
• tap — PostgreSQL 18.4's own TAP tests, run with the real prove / PostgreSQL::Test::Cluster framework, counted per test file. These drive your initdb/pg_ctl/postgres to stand up and manage real clusters.

Every unit counts equally. The compat layer is where a partial server scores; the regression and TAP layers are hard and reward complete, exact feature areas.

Visible vs hidden. /app/tests_dev/ lets you self-check with ./selfcheck.sh, using the exact harness the verifier uses: the compat checks (all visible — they are a public smoke layer) and a visible slice of the regression suite, chosen to span every hidden feature area. The graded set is disjoint and much larger (the full hidden regression suite plus the TAP suite). Matching PostgreSQL's actual behavior is the only thing that generalizes.

What you can use

• Zig and the Zig standard library
• Your own code inside /app/postgres-sqlite
• SQLite (libsqlite3 and its headers are installed)
• The installed psql client for local testing
• The offline PostgreSQL 18 documentation
• Basic system libraries (libc, sqlite3)

What you cannot use

• PostgreSQL source code during the task
• PostgreSQL's regression or TAP test bundles beyond the visible slice
• External Zig packages
• Any dependency that implements PostgreSQL wire compatibility for you
• Wrapping, embedding, exec'ing, or proxying to a real PostgreSQL server (no PostgreSQL server binary exists in either environment)
• Network access at verification time

Working notes

• psql will not give you a prompt until the startup handshake is right: StartupMessage → AuthenticationOk → ParameterStatus (server_version, client_encoding, DateStyle, standard_conforming_strings, integer_datetimes) → BackendKeyData → ReadyForQuery.
• The regression tests are fed through psql -a, so your protocol messages drive psql's own output formatting — get RowDescription (including correct type OIDs, type lengths and typmods) and DataRow right and formatting follows. Reporting everything as text will diverge from the expected output on alignment and on client-side type handling.
• Error compatibility is graded: SQLSTATE codes, severity, and message text all appear in expected output.
• Both the extended query protocol and the simple query protocol are exercised; psql uses extended protocol for parameterized paths.
• Keep the build green and a server startable at all times. Broad partial compatibility scores; an ambitious rewrite that does not build scores zero.

Work autonomously; do not stop to ask for input.