Inside Supabase: The Open‑Source Firebase Alternative Powering Modern Apps

Architecture and Technology Stack

The Supabase repository is structured as a Turborepo monorepo that separates the dashboard, documentation and design‑system into distinct workspaces. The dashboard is built with Next.js and React, styled using Tailwind CSS and componentised through the internal design‑system library. Client‑side tooling relies on Vite for fast module replacement and Vitest for unit testing, while the backend services are expressed in TypeScript and run on either Express or Fastify servers. All code is type‑checked, linted with ESLint and Prettier, and formatted automatically in GitHub Actions workflows. Docker images provide reproducible local and CI environments, and the repository references a range of third‑party services including Supabase itself for auth and storage, Vercel for preview deployments, Stripe for billing, and various cloud providers such as AWS and Google Cloud for auxiliary workloads. Observability today is limited to basic console logging; the findings show no structured JSON logging, no correlation IDs, and no distributed tracing with OpenTelemetry or similar. Test coverage is not enforced - vitest.config.ts lacks any threshold configuration and end‑to‑end tests are absent from the CI pipeline. These gaps contrast with strong foundations in linting, TypeScript adoption and a well‑organised monorepo, indicating where additional rigor would raise the observability and test scores from their current 65 and 40 toward production‑ready levels.

Developer Experience and CI/CD Pipeline

Supabase’s developer experience benefits from a mature monorepo that orchestrates the dashboard, documentation, and design system with Turborepo delivering incremental builds and cached tasks. The codebase leans heavily on TypeScript, which is present in 9939 analyzed files alongside JavaScript, CSS, SQL, and several native languages such as Rust, Kotlin, Dart, Swift, Svelte, Vue and HTML. Linting is enforced through ESLint and Prettier in every GitHub Actions workflow, guaranteeing consistent formatting across pull requests. The repository’s README and DEVELOPERS guide provide step‑by‑step setup instructions, while the component library shares documented UI patterns built with Tailwind CSS. Despite these strengths, the CI pipeline lacks concrete quality gates: vitest.config.ts files in all workspaces contain no test coverage thresholds, and the current test coverage score stands at 40 out of 100. No end‑to‑end testing framework such as Playwright or Cypress is wired into the Actions, and observable tooling is absent, there is no structured JSON logging with correlation IDs and no distributed tracing implementation using OpenTelemetry or similar. Adding coverage enforcement, e2e tests, structured logging, and tracing would tighten the feedback loop and move the observability sub‑score from 65 toward a production‑ready level.

Testing Strategies and Quality Gaps

Supabase’s monorepo shows strong static analysis but its testing strategy reveals significant gaps. No vitest.config.ts file defines a coverage threshold, allowing commits to merge without meeting a minimum bar. The analysis estimates overall test coverage below 60%, far short of the 70% target suggested for production readiness. Moreover, the repository lacks any configured end‑to‑end test framework in its GitHub Actions pipelines, meaning critical user journeys are not validated automatically. Mutation testing and property‑based testing are also absent, limiting confidence in edge‑case handling. On the observability front, the codebase relies on plain console logging that could leak to production and contains no structured JSON logging with correlation IDs. Distributed tracing via OpenTelemetry or similar is not detected, hindering request‑level debugging across services. To close these gaps, the team should add a coverage enforcement block to each vitest.config.ts, set a minimum of 70%, and integrate Playwright or Cypress for end‑to‑end scenarios in CI. Introducing structured logging with correlation IDs and tracing instrumentation will improve diagnosability, while adopting mutation or property‑based tests will strengthen confidence in complex logic.

Observability, Security and Production Readiness

Although Supabase’s monorepo benefits from strict TypeScript typing, ESLint-Prettier linting, and Turborepo-powered builds, its production readiness is hampered by observable and testing gaps. The readiness breakdown gives observability a score of 65 out of 100, security 70, and test coverage only 40, yielding an overall grade of C (66). Specific findings show that no vitest.config.ts file in any workspace enforces a coverage threshold, and end-to-end tests are absent from the GitHub Actions pipelines. Furthermore, the codebase lacks structured JSON logging with correlation IDs and does not implement distributed tracing via OpenTelemetry or similar tools, even though third-party services such as Datadog, Sentry and PostHog are already integrated. The analysis notes that test coverage appears below 60 % based on file density, and recommends adding a minimum 70 % threshold in vitest.config.ts, adopting Playwright or Cypress for critical user journeys, injecting correlation-aware logs, and wiring OpenTelemetry spans across services. Complementary steps include defining SLO-based error budgets, introducing feature flags, enabling SAST/DAST scanning in CI, and documenting architecture decisions. By closing these gaps, Supabase could raise its observability and security scores well above the current levels and achieve a production-grade posture.

Read the full Software Valuation Report (PDF).