Von Supabase kommend
Supabase bündelt Postgres, Auth, Storage und Edge-Funktionen auf seiner eigenen Infrastruktur. Railyard betreibt deinen tatsächlichen Anwendungscode auf einem Server, den du besitzt, mit einem verwalteten Postgres-Addon daneben.
Warum Teams Supabase verlassen
Supabase ist ein starkes Postgres-plus-Auth-plus-Storage-Backend-as-a-Service. Die Reibung zeigt sich, wenn deine App eigene serverseitige Logik jenseits von Edge-Funktionen hat: einen Worker, einen geplanten Job, oder ein Framework wie Rails, Django oder Laravel, das erwartet, als dauerhafter Prozess zu laufen.
Railyard deployt diesen Anwendungscode auf einen Server, den du besitzt, mit verwaltetem Postgres als Addon statt als die ganze Plattform.
Was mitkommt
- Dein Repo, gebaut aus einem Dockerfile, Buildpacks, oder einem Procfile.
- Deine Umgebungsvariablen und Secrets.
- Dein Postgres-Schema und deine Daten, aus Supabase gedumpt und in Railyards verwaltetem Postgres-Addon restored.
- Auth- und Storage-Logik, die du in deiner eigenen App oder mit einer Library neu implementierst, da Railyard sie nicht als verwalteten Service bündelt.
Der Umzug
- Einen Server anbinden: einen bestehenden, oder einen neuen, den Railyard in deinem Cloud-Account provisioniert.
- Dein Repo hinzufügen und ein verwaltetes Postgres-Addon anhängen.
- Deine Daten migrieren mit einem Dump und Restore aus Supabases Postgres.
- Deployen auf eine temporäre URL. Deinen Release-Task laufen lassen und verifizieren.
- DNS umziehen. Dein Supabase-Projekt bedient weiter bis zum Cutover; keine Downtime.
Was anders ist
Ein echter Server für deinen Anwendungscode, mit der Datenbank als Railyard-Addon in deinem eigenen Cloud-Account statt einer geteilten, nutzungsbasiert abgerechneten Plattform.