Spoon

01 — The problem

Restaurant groups run on near-real-time Toast POS data, and turning it into cost, margin, and staffing insight means heavy analytical queries against a database that also serves live traffic.

02 — The decision

Keep Postgres and make it work harder: pool connections through PgBouncer, and move heavy aggregations into indexes, materialized views, and incremental rollups instead of recomputing them on every request.

03 — Architecture

• PostgreSQL connection pooling with PgBouncer
• Indexing, materialized views, and incremental rollups for large datasets

04 — Outcome

In active development — a data layer built to stay fast as restaurant groups and their data grow.

Stack