Why We Built ToasterDB

Every B2B SaaS product eventually becomes a platform. And every platform eventually needs the same things: field-level permissions, multi-tenant isolation, validation that actually works, audit logging, GDPR compliance, and a way to generate forms from your data model without hand-coding every field.

We know because we’ve built it. Twice. And the second time we looked at each other and said: why does every team have to do this?

The timeline every SaaS team recognises

In the first few months you ship fast. Raw SQL, simple CRUD, maybe an ORM. Life is good. You can build a feature in a day.

Six months in, your first enterprise customer arrives. They want to know which roles can see the salary field. They want an audit trail. They want their data isolated from other tenants. You add a WHERE tenant_id = ? to a few queries, write some middleware for role checks, and move on.

By year two, you have 47 files that reference tenant_id. Three different permission systems — one in middleware, one in the database, one that someone wrote in a React hook and never told anyone about. Your “form metadata” lives in a Notion doc that hasn’t been updated since Series A. And you’re spending 20-40% of your engineering time on infrastructure that has nothing to do with your actual product.

By year three, legal walks in. “We need GDPR compliance by next quarter.” Which fields are PII? Nobody knows. Right to erasure across 23 services? Good luck. Who accessed what, when, and why? The auditor is coming on Tuesday.

This is not a failure of engineering. It’s a structural problem. These capabilities don’t compose well when bolted on after the fact, and no team has the luxury of designing them from scratch before they have revenue.

What we wanted to exist

We wanted a single service that understood our data model at a semantic level — not just tables and columns, but fields, relationships, roles, tenants, PII classifications, and validation rules. A service where security and privacy weren’t features you added later but constraints the engine enforced from the first query.

Specifically, we wanted:

• Field-level security declared in the schema, enforced by the query engine. Not middleware. Not application code. The engine.
• Multi-tenancy that was impossible to bypass. Not “remember to add the WHERE clause” but “the engine physically cannot return rows from another tenant.”
• Privacy as architecture, not compliance theatre. PII classification, purpose-based access, masking, encryption, and erasure — all declared alongside the field definition.
• Validation that worked across fields, was evaluated server-side, and couldn’t be bypassed by calling the API directly.
• Form metadata generated from the schema. If you know a field is a currency with FLS rules, you know how to render it.
• An eject button. Build on the platform, but walk away whenever you want. Your data is in PostgreSQL. Your code is React. Nothing proprietary.

Nothing like this existed. Supabase gives you PostgREST and auth, but no FLS, no validation engine, no privacy primitives. Hasura gives you GraphQL, but you’re still writing authorisation rules by hand. Salesforce has all of these features but locks you in so thoroughly that “ejecting” means “rewriting your entire product.”

So we built it

ToasterDB is a stateless HTTP service that sits on top of PostgreSQL. You define your schema — objects, fields, relationships, security rules, privacy classifications, validation expressions — and the engine handles the rest. Every query goes through ToastQL, our query language that compiles to SQL with all security, privacy, and tenant isolation enforced automatically.

The key insight is that if you know the schema, you can enforce everything at the engine level. You don’t need application code to check permissions. You don’t need middleware to filter PII. You don’t need manual WHERE clauses for tenant isolation. The engine reads the schema and generates the correct SQL every time.

This means:

• A viewer who shouldn’t see budget fields will never receive them — the engine strips them from the response.
• An analytics query with purpose: "analytics" will automatically mask PII fields and apply differential privacy budgets.
• A DELETE /privacy/erase call will null every PII field across every object for a given subject, preserving the audit trail.
• A developer using the MCP server in Claude Code or Cursor will introspect the schema, discover which fields exist and which permissions apply, and generate correct CRUD code without guessing.

Why PostgreSQL

We considered building our own storage engine. For about thirty seconds.

PostgreSQL is the best-tested, most reliable relational database in the world. Your team already knows it. Your backup strategy already covers it. Your monitoring already watches it. ToasterDB creates real tables, real columns, real indexes, and real foreign keys. If you ever stop using ToasterDB, your data is sitting right there in PostgreSQL, exactly where you left it.

This was a non-negotiable design constraint: your data is always yours. No proprietary format. No data hostage situations. No “export” that gives you a ZIP file of JSON and wishes you good luck.

The eject promise

Beyond the data layer, ToasterDB generates applications from your schema: admin consoles, web apps, mobile apps. But every generated app can be ejected to standard code. toaster eject --web gives you a React Router project. toaster eject --mobile gives you a React Native project. Real components, real hooks, real TypeScript types.

The ejected code still talks to ToasterDB for security and validation — you’d be foolish to reimplement FLS in your frontend — but the UI is yours. Iterate on it, redesign it, or throw it away and write your own.

We believe the best way to prevent lock-in is to make the exit path so clean that customers stay because the product is good, not because leaving is expensive.

What’s next

We’re focused on three things:

1. The data engine is production-ready. Schema, FLS, RLS, validation, privacy, ToastQL, events, CDC — all shipping.
2. The console and app builder are in beta. Define pages, navigation, and themes from your schema.
3. Native mobile is coming. The same schema-driven approach, compiled to a native shell you can submit to the App Store.

If you’re building B2B SaaS on PostgreSQL and you’re tired of rebuilding the same plumbing, give it a try. The free tier gives you 10 objects and 50K queries — enough to build something real and see if it fits.

And if you’re past that stage and you need self-hosted deployment, VPC isolation, or custom compliance — let’s talk.