Ihre Datenbank. Ihre Regeln.
Ihre Geschwindigkeit.
Relpin nutzt per-org Postgres-Datenebenen, serverseitige SQL-Ausführung und governed Connector-Pfade. BYOD und breitere Datenquellen-Konnektoren sind geplante Erweiterungen.
Eine Org. Governed Data Plane.
Klare Umgebungsgrenzen.
Relpin baut auf einer DB-per-Org-Baseline mit DEV-, TEST- und PROD-Umgebungsschemas auf, plus DB-per-Env-Pfad für Enterprise-Isolation.
Jede Organisation erhält ein dediziertes Postgres mit Schemas im Org-Scope.
DEV, TEST und PROD Schemas halten Umgebungsgrenzen explizit und abfragbar.
Tenant-DB-Credentials bleiben env-basiert und serverseitig — landen nie im Browser.
Managed integriertes Postgres wird in AWS-Regionen bereitgestellt. EU Central - Frankfurt ist der Beta-Standard; weitere Regionen sind fuer Teams verfuegbar, die Daten naeher an Operatoren oder Kunden platzieren muessen.
SQL auf dem Server.
Nicht im Browser.
Abfragen laufen serverseitig in nativem SQL. Sortierung, Filterung, Aggregation und Paginierung werden an Postgres delegiert — nicht in den Browser-Speicher geladen.
Filter, Sort und Pagination kompilieren zu SQL. Publish schlägt fehl, wenn die Query client-side ausgewertet würde.
Queries laufen in Postgres — kein 100k-Zeilen-Browser-Memory-Hotloop.
Parametrisiertes SQL mit schema-qualifizierten Tabellennamen — typed Bindings, kein String-Concat.
Ihr Postgres.
Ihre Infrastruktur.
Geplanter BYOD-Support zielt auf bestehende Postgres-Infrastruktur, während Credential-Handling und Tenant-Routing serverseitig bleiben.
Bestehende Instanzen anvisieren, ohne serverseitige Credential-Grenzen aufzugeben.
Tenant-DB-Credentials bleiben in Server-Environment oder Secret-Bindings — außer Browser-Reichweite.
Per-Org- und Per-Env-Routing-Checks bleiben über dieselbe Control Plane erzwungen.
Standard-PostgreSQL-Verbindungsstring
PgBouncer oder Supabase Pooler
Enterprise-Implementierungsdetail
Tenant-aware serverseitiges Routing
Slack ist der Referenz-Connector.
Breiterer Katalog geplant.
Das governed Invocation-Framework ist heute live. Slack ist der Referenz-Connector — serverseitige Aufrufe mit Idempotency Keys, Retries, SSRF-geschütztem Egress und Capability Gates. Ein breiterer Katalog aus Datenbank-, API- und Custom-Source-Konnektoren ist über dasselbe Framework geplant.
Connector-Aufrufe laufen serverseitig über einen queued Worker mit Idempotency Keys, Retries und Capability Gates.
Slack ist heute der Referenz-Connector — SSRF-geschützter Egress, Capability Gating und auditierte Invocations.
Database-, REST-, GraphQL- und Custom-Source-Konnektoren sind über dasselbe governed Framework geplant.
Was Teams darauf bauen.
Von operativen Dashboards bis Audit-Workflows trägt die Datenebene governed interne Tools.
Analyse-Dashboards
Operative Dashboards mit serverseitigen Aggregationen, Filtern und Drill-down-Ansichten auf governed Daten.
Datenverwaltungstools
Vollständige CRUD-Oberflächen mit Validierung, Suche, Massenoperationen und eingebautem Audit-Logging.
Kunden-360-Ansichten
Kundenansichten über governed Datenquellen, wenn Connector-Abdeckung wächst.
Audit- & Compliance-Reporting
Unveränderliche Audit Trails mit SQL-abfragbaren Logs, gefiltert nach Akteur, Aktion und Zeitraum.
Datenmigrations-Pipelines
Schema- und Datenänderungen laufen über geprüfte, auditierbare Plattform-Operationen.
Multi-Source-Reporting
App-Daten mit weiteren governed Quellen kombinieren, wenn Connector-Abdeckung wächst.
Schluss mit Abfragen im Browser.
Anfangen mit SQL.
DB-per-Org-Datenebene. Serverseitiges SQL. Governed Connector Calls. Gebaut für Teams, die operative Daten ernst nehmen.
Offene Beta · Demo-Workspace enthalten · Governance-fokussiert
Serverseitiges SQL · Mandanten-isoliert · Env-basierter DB-Zugriff · Governed Connectors