tinbase: A Local Supabase Alternative That Runs as a Single Process

A Complete Backend in One Process

For developers familiar with Supabase, setting up a local development environment often means spinning up a massive Docker container stack—typically a dozen or more containers working together, covering Postgres, Auth, Storage, Realtime, API gateway, and other services. This architecture makes perfect sense in production, but for local development or lightweight testing scenarios, it's overkill.

Supabase is an open-source Firebase alternative built on PostgreSQL, providing database, authentication, file storage, real-time subscriptions, and edge functions as a one-stop backend service. In the BaaS (Backend as a Service) market, Firebase has long dominated—acquired by Google in 2014, it's known for its NoSQL document database (Firestore) and rich mobile SDKs. However, Firebase's proprietary nature, the limitations of its NoSQL data model for complex queries, and the risk of runaway bills from usage-based pricing have driven many developers toward open-source alternatives. Since its founding in 2020, Supabase has risen rapidly, raising over $116 million in funding with more than 70,000 GitHub stars. Its core competitive advantages are: open-source transparency, building on the mature relational database PostgreSQL, and full compatibility with the existing SQL ecosystem.

Its local development tool, supabase CLI, orchestrates multiple containers via Docker Compose, including postgres (database), gotrue (authentication service), storage-api (file storage), realtime (WebSocket real-time push), postgrest (auto-generated REST API), kong (API gateway), studio (admin panel), and more. This microservices architecture faithfully replicates cloud behavior, but the resource consumption on development machines is significant—typically requiring 4GB+ of memory, pulling several GB of images on first startup, and Docker Desktop itself adds extra resource overhead on macOS and Windows.

Notably, Docker Desktop on macOS actually launches a Linux virtual machine (via Apple Hypervisor Framework), and this virtualization layer introduces inherent CPU and memory overhead. For MacBook Air users with only 8GB of RAM, the Supabase local stack can consume nearly half of available memory. Combined with Docker Desktop's pricing changes for large enterprises since 2021, community demand for non-Docker local development solutions has grown increasingly strong.

tinbase was born to address exactly this pain point. It's a fully Supabase-compatible backend solution whose core selling point is: compressing what originally required 12 containers into a single process. Developers can get an API experience consistent with Supabase without installing or managing Docker.

The project was built by Sanket Sahu, released under the MIT open-source license, and has launched on Product Hunt, categorized under open-source tools, developer tools, and databases.

Real Postgres 17, Not an Emulation Layer

The biggest difference between tinbase and some "Supabase-compatible" projects is that it runs real Postgres 17, not a compatibility layer simulated through SQLite or another database. This means the database features developers use in their local environment remain highly consistent with production.

PostgreSQL 17 was officially released in September 2024, bringing several important improvements: incremental backup (pg_basebackup --incremental), RETURNING clause support for MERGE statements, JSON_TABLE function enhancements, improved query parallel execution performance, and multiple optimizations for logical replication. For Supabase users, Postgres 17's significance also lies in its VACUUM performance improvements (up to 20x faster) and better handling of large-scale concurrent connections. tinbase chose Postgres 17 over earlier versions to ensure developers can use the latest database features during development.

More importantly, tinbase preserves Postgres's core capabilities, including RLS (Row Level Security). RLS is the cornerstone of Supabase's permission model—many applications rely on it for multi-tenant isolation and user data access control. If the local environment can't fully reproduce RLS behavior, developers often don't discover permission configuration issues until deployment. tinbase's complete support for RLS in a single process greatly reduces the risk of "works locally, fails in production."

From a technical perspective, Row Level Security is a native security feature introduced in PostgreSQL 9.5 that allows database administrators to define fine-grained access control policies at the table level. Unlike traditional application-layer permission checks, RLS pushes security logic down to the database layer—even if application code has vulnerabilities, the database can prevent unauthorized access. In Supabase's architecture, clients query the database directly through PostgREST, making RLS policies the sole security barrier.

PostgREST itself is a high-performance tool written in Haskell that introspects PostgreSQL's system catalog to automatically expose database tables, views, and stored functions as RESTful HTTP endpoints. For example, a table named todos automatically generates corresponding CRUD endpoints with support for complex nested queries (JOINs are automatically inferred through foreign key relationships). Its security model is entirely delegated to PostgreSQL's role system—each API request executes as the anon or authenticated role, with RLS policies determining which rows are visible to that role. For tinbase to achieve full Supabase compatibility, it must precisely reproduce PostgREST's URL routing rules and query parameter parsing logic.

Developers define policies through CREATE POLICY statements, combining functions like auth.uid() to implement common patterns such as "users can only access their own data." Since RLS policy behavior is highly dependent on PostgreSQL's execution engine, alternative databases like SQLite have difficulty fully reproducing its semantics, especially for complex policies involving subqueries, JOINs, or custom functions.

Complete Feature Matrix

tinbase integrates Supabase's four core services within a single process:

• Postgres 17: Real database engine with RLS support
• Auth: Identity authentication and user management
• Storage: File storage service
• Realtime: Real-time data subscriptions

The Auth service corresponds to Supabase's GoTrue component—an authentication server written in Go (originally developed by Netlify, independently maintained after Supabase forked it). GoTrue implements complete modern authentication flows: email/password registration and login, Magic Links, OAuth social login (supporting 30+ providers including Google, GitHub, Apple), phone SMS OTP, and multi-factor authentication (MFA). The JWTs (JSON Web Tokens) it issues contain user ID, role, and metadata information. PostgREST validates the JWT and exposes the user identity to RLS policies through the auth.uid() function. Reproducing this authentication logic in a single process requires tinbase to implement the complete chain of JWT issuance/verification, password hashing, session management, and OAuth callback handling.

The Realtime service in Supabase's official implementation is built on the Elixir/Phoenix framework, leveraging PostgreSQL's Logical Replication and WAL (Write-Ahead Log) to monitor database changes and push change events to subscribing clients via WebSocket. It supports three modes: database change listening (Postgres Changes), Broadcast (direct client-to-client communication), and Presence (online status tracking). tinbase in its single-process environment likely uses PostgreSQL's LISTEN/NOTIFY mechanism as an alternative implementation—while the underlying mechanism differs, the client API maintains interface compatibility.

This combination essentially covers the primary needs of Supabase application development, enabling developers to locally complete the full workflow from data modeling and permission control to real-time functionality validation.

Zero-Modification Migration: supabase-js Works Directly

Another major design highlight of tinbase is its compatibility with the existing ecosystem. The project explicitly states: the supabase-js client library works without any modifications. This means projects already built on Supabase can switch to tinbase for local development almost seamlessly, without rewriting business code or adjusting client calling logic.

supabase-js is Supabase's official JavaScript/TypeScript client library and the most widely used SDK in the entire Supabase ecosystem, with over 500,000 weekly npm downloads. It wraps calls to PostgREST (data queries), GoTrue (authentication), Storage API (file management), and Realtime (WebSocket subscriptions), providing a unified chainable API. After developers initialize with createClient(url, anonKey), they can use intuitive syntax like .from('table').select() to interact with the database. tinbase's compatibility with supabase-js means it implements the complete HTTP/WebSocket interface specifications of these underlying services—clients only need to change the connection URL to switch backends.

This "plug-and-play" compatibility is especially friendly for team collaboration and CI/CD workflows. Developers can iterate quickly locally with tinbase while deploying the same codebase to Supabase cloud, with consistent behavior between the two. In CI/CD scenarios, tinbase's single-process nature means test environment startup time can shrink from 30-60 seconds for a Docker stack to just a few seconds, significantly improving continuous integration feedback speed.

Running a Complete Backend in a Browser Tab

Perhaps tinbase's most surprising capability is that the entire backend can run in a browser tab. This feature opens up many interesting use cases:

• Interactive tutorials and demos: Run a complete backend directly in a webpage without a server
• Prototype validation: Quickly build playable demos that others can use instantly when shared
• Offline development: Complete the full development loop locally without depending on network or cloud services

Running real Postgres in a browser typically relies on WebAssembly technology (such as PGlite-type solutions). WebAssembly (Wasm) is a binary instruction format that executes at near-native speed in modern browsers, officially standardized by the W3C in 2019, and currently supported by all major browsers.

PGlite is a project developed by the ElectricSQL team that compiles PostgreSQL to Wasm, enabling it to run in Node.js or browser environments with a compressed size of only about 3MB per instance. It cross-compiles PostgreSQL's C source code into a Wasm module using the Emscripten toolchain and uses virtual file systems (such as IndexedDB or OPFS) for data persistence.

Compiling PostgreSQL to Wasm is an extremely challenging engineering task. PostgreSQL's codebase exceeds 1.3 million lines of C code with deep dependencies on POSIX system calls (such as fork(), mmap(), signal handling, etc.), which Wasm's sandbox environment doesn't provide. Emscripten offers partial compatibility through an emulation layer, but PostgreSQL's multi-process architecture (forking a backend process for each connection) must be restructured into a single-process model. PGlite's solution runs PostgreSQL in single-user mode and replaces native file operations with Emscripten's async I/O. For data persistence, the browser environment can use IndexedDB or Origin Private File System (OPFS, supported since Chrome 86+), with the latter providing performance closer to native file systems. These limitations mean PostgreSQL in the browser doesn't support concurrent connections or certain C extensions requiring OS-level support, but the core SQL engine and RLS functionality run completely—powerful enough for development and demo scenarios.

tinbase combines this capability with a complete Supabase API, forming an extremely lightweight, portable backend environment.

What This Means for Local Development Experience

tinbase reflects a clear trend in the current developer tools space: reducing the complexity of local development. In recent years, as cloud-native architectures have become widespread, local development environments have paradoxically grown heavier—a complete tech stack may require significant memory and disk resources, with slow startup times and tedious configuration.

Single-process architecture is a reverse approach to microservices architecture. In the microservices model, each service is independently deployed and scaled, suitable for large-scale production environments but increasing operational complexity. Single-process architecture compiles or embeds all functional modules into a single executable, replacing network calls with in-process communication, dramatically reducing latency and resource consumption. This pattern isn't uncommon in developer tools—SQLite itself is a paradigmatic embedded single-process database, and Pocketbase (a single-file backend written in Go, embedding SQLite + auth + file storage + real-time subscriptions) uses a similar philosophy and has achieved tremendous community success. Litestream demonstrates how single-process SQLite can achieve production-grade reliability through streaming replication. tinbase's uniqueness lies in applying this single-process philosophy to the PostgreSQL ecosystem—preserving all capabilities of a relational database rather than retreating to SQLite's feature subset.

For tinbase, single-process means startup time could be at the seconds level, with memory usage controllable at the hundreds-of-MB level—far below the resource requirements of a Docker container stack. This difference gets amplified repeatedly in daily development—every branch switch requiring a database reset, every test suite run requiring backend startup, every schema modification requiring a service restart. The experiential gap between second-level and minute-level startup is a qualitative leap.

tinbase uses its single-process architecture and browser-runnable capability to seek balance between "feature completeness" and "lightweight ease of use." For individual developers, small teams, and educational/demo scenarios, the appeal of this approach is obvious.

Of course, as a new project that just launched on Product Hunt, tinbase's maturity, performance characteristics, and compatibility in complex production-grade scenarios still await community validation. But its approach is worth watching—it reminds us that there's still significant room to optimize the local development experience for backend services.

For developers who frequently use Supabase, tinbase at least offers a local alternative worth trying: no Docker needed, one process, real Postgres.