Keep the application dialect, change the transport
Gogs uses both GORM and XORM. Rather than rewriting the application around another dialect, the database.pizza fork keeps their SQLite SQL generation and replaces the database/sql transport layer.
The custom internal/pizzadriver driver speaks the PostgreSQL simple-query protocol through pgx. The managed proxy accepts the connection, authenticates the API key, and forwards it to the scoped PizzaSQL tenant.
Gogs (GORM + XORM, SQLite dialect) -> internal/pizzadriver -> pgproxy -> PizzaSQL -> PizzaKV
Compatibility work is application-specific
Gogs migrations and runtime queries depend on more than SELECT and INSERT. The engine needed SQLite catalog reads through sqlite_master and sqlite_schema, the PRAGMAs used by the ORM, session-local generated-row helpers, unique indexes, qualified wildcards, and correct JOIN plus WHERE execution.
Some details are deliberately narrow. For example, the fork uses a surrogate lfs_object table shape because the engine does not retain Gogs' usual composite primary-key shape. Backup and restore are blocked for this backend rather than pretending that a lossy round trip is safe.
- Catalog PRAGMAs are read-only allowlisted by the proxy.
- DROP INDEX maps to the alter_table scope so a scoped API key can perform the migrations it needs.
- The driver obtains generated IDs on the same session, avoiding cross-connection ambiguity.
A useful constraint
The result is not a claim that every SQLite application will run unchanged. It is a tested integration target: a real application, a concrete driver, and a documented set of engine features. Each limitation stays explicit so the next compatibility change can be verified against a known workload.