vs a backend-as-a-service
A backend-as-a-service gives an application developer a hosted database, authentication, file storage, and a generated data API. Supabase puts a managed Postgres behind auto-generated REST and GraphQL, row-level security, realtime subscriptions, and client SDKs for web and mobile. Firebase provides similar application primitives around a document store with offline sync. The category is organized around web and mobile application setup rather than dataflow execution.
Redgold solves a different starting problem. It is a data engine plus a Kubernetes-integrated runtime where an application is a checked-in Rust serde schema encoded with CBOR, a pipeline manifest, an edge route, and executor-run transform code over engine storage. The data layer is analytics-shaped — a columnar cold tier alongside a hot Postgres tier under one addressing model — rather than a single row-store fronted by a CRUD API.
Criteria
| Criterion | Redgold | Supabase / Firebase-class BaaS |
|---|---|---|
| Data model | Content-addressed Rust serde rows encoded with CBOR across a Lance/Parquet cold tier and a Postgres hot tier (data and pipelines) | Managed Postgres (Supabase) or a hosted document store (Firebase), exposed directly to clients |
| Deploy target | Your own Kubernetes cluster via a Git-backed build and ArgoCD (managed deployment) | The vendor's cloud; no cluster to run |
| Extensibility | Review a Rust serde schema, pipeline TOML, transform code, and tests in Git; Redgold provisions and operates the managed application (managed application artifacts) | Edge/serverless functions, database triggers, SQL views |
| Self-host story | Managed during onboarding today; a single-machine Docker Compose evaluation sandbox exists for local trials, and broader self-service self-hosting is planned | Supabase is self-hostable via its own Docker stack; Firebase is hosted-only |
| Auth and client SDKs | No hosted auth product or first-class mobile/web client SDKs at this layer (planned) | Built-in auth, generated client SDKs, realtime subscriptions |
| AI / agent integration | Coding-agent fleet in isolated pods plus model API routing, alongside the same data layer (AI agents, LLM API) | None built in; you integrate a model provider yourself |
| Maturity | Early, single-operator; the generic external data-authoring surface is still being consolidated (data availability) | Mature, widely deployed, large ecosystem and community |
Category boundary
A BaaS centers on web and mobile application primitives: auth, a database, storage, realtime updates, and client SDKs. Redgold does not currently provide equivalent sign-in flows, generated client libraries, or offline sync. Its scope starts with typed pipeline applications, managed data processing, agent workspaces, and deployment on a cluster.
When Redgold fits
Redgold fits when the application is data-and-pipeline shaped rather than CRUD-shaped: records arrive from ingestion or agents, transforms run over them with content-addressed caching, and you query the result. It fits when you want that to run on your own Kubernetes with GitOps deployment, and when a fleet of coding agents operating the same platform is part of the point. If you would otherwise combine a BaaS with a separate analytics warehouse and a separate agent runtime, the integrated shape is the trade Redgold is offering, against the maturity and polish you give up.