A second application, a different shape of pressure
Vikunja uses XORM with its SQLite dialect, but its schema and query patterns differ substantially from Gogs. The database.pizza fork adds a PizzaSQL database/sql driver in pkg/db/pizzasql.go and carries those queries over the PostgreSQL simple-query protocol.
That path runs through the same managed proxy and scoped PizzaSQL tenant model, which lets us learn whether compatibility work generalises beyond one application.
Vikunja (XORM, SQLite dialect) -> pkg/db/pizzasql.go -> pgproxy -> PizzaSQL -> PizzaKV
Queries that made the difference
Vikunja exposed SQL features that are easy to overlook in a small test suite. Its migrations, permissions, and task views require both recursive and non-recursive CTEs, ROW_NUMBER() window functions, explicit NULL ordering, conflict updates, and correlated EXISTS checks.
The proxy also had to understand that a statement beginning with WITH is not necessarily an unknown operation. It classifies the main statement after the CTE list, while respecting quoted text and parenthesised expressions, so the normal scope checks still apply.
- ON CONFLICT supports DO UPDATE and DO NOTHING against unique indexes, including excluded.col references.
- ORDER BY supports NULLS FIRST and NULLS LAST for task ordering.
- Correlated EXISTS is evaluated safely without holding the scan lock across the dependent query.
Keep the boundary testable
The integration validates a local migration suite and core project and task CRUD through the HTTP API. It does not turn the engine into a drop-in SQLite replacement or promise every Vikunja feature in every deployment. The documented capability list is the contract we can test and extend.