ADR 001: Self-hosted PostgreSQL instead of Supabase
Source:
g2labs-in/linode-infra@4812f10·docs/adr/001-self-hosted-postgres.md· updated 2026-05-26
Date: 2026-05-25 Status: accepted
Context
Billuu was using Supabase free tier for PostgreSQL. The database is hosted in aws-1-ap-south-1 (Singapore), while the application VPS is in ap-west (Mumbai). This geographic distance causes high latency for every database query, degrading the POS application experience.
Additionally, Supabase free tier imposes connection limits, storage limits, and pauses inactive projects — unacceptable for a production SaaS.
Decision
Deploy a self-hosted PostgreSQL 18 instance on a dedicated Linode VPS in the same region (ap-west/Mumbai) as the application server, connected via Tailscale private network for zero-latency, encrypted communication.
Alternatives considered
| Option | Pros | Cons | Rejected because |
|---|---|---|---|
| Upgrade Supabase tier | No infra work | Still remote latency, ongoing cost | Doesn’t solve latency |
| PostgreSQL on same VPS | Zero extra cost | Single point of failure, DB competes with app for RAM | No fault isolation |
| Managed DB (Linode Managed) | Automatic backups, HA | Higher cost, less control | Budget constrained ($100 credit) |
| Self-hosted on dedicated VPS | Low latency, full control, scalable | Manual backup setup needed | Chosen |
Consequences
- Positive: Sub-millisecond DB latency (same data center on Tailscale), full control over extensions and config, no vendor lock-in
- Negative: Manual backup management required, no automatic failover (acceptable for early stage with zero paying users)
- Neutral: Added $12/mo to infra cost ($36/mo total)