A database should carry real work
A database service can pass isolated tests and still fail at the seams where an application, a driver, a proxy, and storage meet. We want those seams to be visible before users find them.
That is why we run real open-source applications on the managed database.pizza stack. Gogs gives us a Git service with both GORM and XORM. Vikunja gives us a larger task-management workload built on XORM. Neither is a synthetic compatibility fixture.
The path under test
Both applications generate SQLite-flavoured SQL, then reach a managed tenant over a PostgreSQL wire connection. The unusual combination is deliberate: it forces us to be precise about the SQL surface applications actually rely on.
Application -> SQLite dialect -> PostgreSQL wire proxy -> PizzaSQL -> PizzaKV
- The proxy authenticates API keys, applies scopes and quotas, and routes each request to the correct tenant.
- PizzaSQL executes the application query surface and exposes HTTP plus PostgreSQL-compatible interfaces.
- PizzaKV provides the persistent storage engine beneath PizzaSQL.
What we learn
Dogfooding turns compatibility claims into specific workloads. Startup migrations expose catalog and DDL gaps. ORM insert paths expose generated-ID and uniqueness behaviour. Permission queries exercise joins, common table expressions, window functions, and subqueries.
It also keeps the boundary honest. database.pizza is in open beta and does not claim general production compatibility. Real deployments help us identify the next narrow capability to verify instead of promising an entire database dialect.