Open-Source-Optionen für Steuerdaten

OpenMetadata und Lake-Formate listen sales_otc-Tabellen — Status-Mappings und Berechtigungs pflegen sie nicht. Der Control-Data-Stack braucht eigene Pflegeorte; Catalog allein ersetzt sie nicht.

In einem Satz: Bauen Sie einen minimal lebensfähigen Steuerdaten-Stack um PostgreSQL für fachlich gepflegte, multi-Consumer-Steuertabellen.

Problem

Teams suchen oft nach einem „Steuerdaten-Produkt“ und landen bei drei Fehlstarts.

Der erste ist ein Katalog. OpenMetadata oder DataHub können Verantwortung, Lineage und Glossarbegriffe zeigen. Sie werden nicht zum Schreibpfad für Status-Mappings oder Kostenstellenhierarchien. Sichtbarkeit ohne governte Tabelle lässt Consumer weiterhin Inline-LOAD INLINE, Excel-Sheets oder Notebook-Dictionaries lesen.

Der zweite ist eine Lake-Tabelle als Pflege-UI. Iceberg oder Delta können große, historisierte Referenz-Snapshots verteilen. Sie geben Stewards keine Validierung, Freigabe, Audit darüber, wer eine Zeile geändert hat, und keinen stabilen Schlüsselvertrag. Eine CSV in Object Storage ist weiterhin der Failure Mode „Datei als führende Quelle“ aus Excel und CSV als führende Quelle zerstören Pipelines.

Der dritte ist ein generisches Low-Code-Grid auf einem undefinierten Schema. Adminer, Metabase-Formulare oder NocoDB können Zeilen schnell editieren. Ohne Migrationen, Constraints, Audit und eine veröffentlichte Consumer-View wird das Grid zu einem zweiten Excel mit schönerer URL.

Der echte Bedarf ist klein: einige Dutzend bis einige Tausend Zeilen, die Fachbereiche ändern, die mehrere BI-Apps und SQL-Jobs teilen müssen und die Spaltenumbenennungen sowie Owner-Übergaben überstehen. Dieser Bedarf wurde in Steuerdaten vor dem Umzug klassifizieren klassifiziert und in Wohin Steuerdaten gehören platziert. Die Technologieentscheidung kommt nach diesen Entscheidungen.

Entscheidung

Bauen Sie einen minimal lebensfähigen Steuerdaten-Stack um PostgreSQL für fachlich gepflegte, multi-Consumer-Steuertabellen. Fügen Sie eine Stewardship-UI nur hinzu, wenn der Prozess dazu passt. Nutzen Sie Lake-Formate für Verteilung und Analytik, nicht für Stewardship. Nutzen Sie den Katalog für Discovery und Evidenz, nicht als System of Record.

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

PostgreSQL          persistence, constraints, RLS, migrations
Stable views/API    consumer contract
Backup + access     operational baseline
Optional UI         Adminer / forms / NocoDB / DIY — only if process fits
Catalog             ownership, lineage, recertification evidence
Lake/warehouse      snapshots and analytic spread — not the write path

Die Default-Platzierung bleibt eine kleine relationale Steuerdatenbank. Das passt zu Fachlogik außerhalb der BI-Apps halten: geteilte Wahrheit lebt außerhalb von Qlik, Power BI und Excel; Consumer bleiben dünn.

PostgreSQL als Kern

PostgreSQL ist die Default-Open-Source-Persistenzschicht, weil sie zur Nutzung von Steuerdaten passt:

• stabile Primärschlüssel und Fremdschlüssel zwischen Mapping-Tabellen;
• CHECK-Constraints und Domains für geschlossene Vokabulare;
• Schemas als Produktgrenzen (control_sales, control_access);
• Views als veröffentlichter Vertrag, während Basistabellen sich weiterentwickeln;
• Row-Level Security, wenn Berechtigungs- oder personenbezogene Daten-nahe Listen steward-scoped Writes brauchen;
• Migrations-Tooling (Flyway, Liquibase, Sqitch oder SQL-Dateien in CI), damit Schemaänderungen reviewbar sind;
• Point-in-Time-Backup und Restore als First-Class-Betriebsanforderung.

Typische Objekte:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

control_<domain>.<asset>_base     editable table
control_<domain>.v_<asset>        published consumer view
control_<domain>.<asset>_audit    append-only change log (or temporal)

Veröffentlichen Sie Consumer auf der View, nicht auf der editierbaren Basistabelle. BI-Reloads, dbt-Sources und APIs dürfen nicht von UI-Spaltennamen oder Draft-Zeilen abhängen.

DuckDB, SQLite und Lake-Formate — klare Grenzen

DuckDB ist hervorragend für lokale Analytik, Reconciliation und einmalige Validierung von Steuerdaten-Extrakten. Es ist kein Enterprise-Stewardship-Store: Multi-User-Write-Concurrency, dauerhafte gemeinsame Zugriffskontrolle und betriebliches Backup/Restore für Fach-Stewards sind nicht seine Aufgabe.

SQLite passt zu Edge-Geräten, Single-Node-Tools und eingebetteten Prototypen. Es ist eine schlechte gemeinsame Steuerdatenbank für mehrere Stewards und produktive BI-Consumer.

Iceberg / Delta (mit Table Catalog) passen zu großen historisierten Referenzverteilungen, Cross-Engine-Reads und warehouse-ähnlichen Snapshots bereits governeter Steuerprodukte. Sie ersetzen nicht:

• Steward-Schreibworkflows;
• zeilenweise Validierung beim Editieren;
• Freigabe-Queues für Berechtigungs;
• Audit „wer hat dieses Mapping gestern geändert?“ für eine fünfzigzeilige Tabelle.

Anti-Pattern: „Wir legen das Mapping in den Lake, dann ist es governed.“ Verteilung ist keine Pflege.

Stewardship-UIs als optionale Beispiele

Behandeln Sie Folgendes als Beispiele mit Grenzen, nicht als empfohlene Produkt-Shortlist:

Übernehmen Sie eine UI nur, wenn sie serverseitige Validierung, rollenbasierte Schreibrechte, Audit-Evidenz und einen stabilen Consumer-Vertrag unterstützt — oder davor sitzt. Kann die UI das nicht, behalten Sie Postgres + Migrationen und wechseln Sie zu einem bewusst kleinen DIY-Schreibpfad in Einfache Stewardship-Lösungen selbst bauen, wenn kein Tool passt.

Katalog für Sichtbarkeit, nicht zum Schreiben

Verdrahten Sie Steuer-Schemas in OpenMetadata oder DataHub, damit Stewards und Consumer sehen:

• Owner und Steward;
• Beschreibung und Klassifikation;
• Lineage in Qlik-Apps, Power-BI-Modelle und Warehouse-Jobs;
• Quality- oder Freshness-Signale, wo sinnvoll;
• Rezertifizierungsdaten.

Das ist die governance-seitige Oberfläche aus dem Catalog Deep Dive. Der Katalog wird nicht zum Editor. Teil 8 bindet dieselben Assets an einen operativen Produktvertrag — unabhängig davon, ob der Schreibpfad OSS-UI oder DIY ist.

Entscheidungsregel

OSS zuerst für Persistenz und Vertrag. UI nur, wenn der Pflegeprozess passt. Lake und Katalog erweitern Verteilung und Sichtbarkeit — sie ersetzen kein Stewardship.

Passt innerhalb weniger Wochen keine UI, warten Sie nicht auf ein MDM-Programm. Bevorzugen Sie einen kleinen Custom-Schreibpfad gegenüber Excel als führender Quelle und gegenüber einem ungesteuerten Grid.

Checkliste

• Steuerdaten-Assets sind klassifiziert und haben eine Platzierungsentscheidung, bevor Tooling gewählt wird.
• PostgreSQL (oder eine äquivalente relationale Steuer-DB) ist System of Record für geteilte, fachlich gepflegte Tabellen.
• Schemaänderungen laufen über Migrationen in Version Kontrollregel.
• Nutzer lesen veröffentlichte Views oder APIs, nicht editierbare Basistabellen oder UI-Grids.
• Constraints decken Schlüssel, geschlossene Vokabulare und erforderliche Fremdschlüssel ab.
• Backup, Restore und Zugriffsrollen sind für das Steuer-Schema definiert.
• DuckDB/SQLite sind auf analytische oder Edge-Rollen begrenzt, nicht auf gemeinsames Stewardship.
• Iceberg/Delta nur für Verteilung/Snapshots bereits vertraglich gebundener Daten.
• Jede Stewardship-UI wurde auf Validierung, Audit, AuthZ und Vertrag bewertet — und bei Schwäche abgelehnt.
• Der Katalog zeigt Verantwortung, Lineage und Review-Kadenz für die Steuerprodukte.
• Excel/CSV bleiben Import-Staging oder Analyse-Nutzer, nicht der führende Vertrag.
• Fallback auf DIY-Stewardship ist explizit, wenn keine OSS-UI passt.

Artefakt

Erstellen Sie ein Minimal Viable Control Stack-One-Pager pro Umgebung (dev/test/prod).

Pflichtfelder:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

control_db_engine: PostgreSQL <version>
instance / database / schema boundary
migration_tool_and_repo_path
backup_policy_and_owner
write_roles / read_roles
published_contracts: list of views or API endpoints
optional_stewardship_ui: name | none | diy-planned
ui_fit_assessment: validation / audit / AuthZ / contract (pass|fail)
catalog_service_and_fqn_pattern
lake_distribution: none | iceberg/delta snapshot job
pilot_assets: 1–3 table families
go_live_gate: backup tested, one consumer dual-run, owner named

Ergebnisse: genehmigter Stack für die Pilot-Domain, abgelehnte UI-Optionen mit Gründen und ein klarer Trigger, Teil 7 DIY zu starten, wenn optional_stewardship_ui = none und Fachbereiche selbst pflegen müssen.

Tools

• PostgreSQL + Migrations-Tooling in CI — Persistenz und reviewbare Schemaänderung.
• Architecture Fit — Steuer-DB vs. Lake vs. Warehouse-Platzierung bestätigen, bevor eine UI gekauft wird.
• OpenMetadata- oder DataHub-Connectoren — Steuer-Schemas für Verantwortung und Lineage harvesten (Was Governance von einem Katalog braucht).
• Optional: Adminer / Metabase / NocoDB erst nach bestandener UI-Fit-Bewertung.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Vorher: Wohin Steuerdaten gehören
• Weiter: Einfache Stewardship-Lösungen selbst bauen, wenn kein Tool passt
• Fachlogik außerhalb der BI-Apps halten
• Excel-Schatten-BI und Kennzahlen-Drift — Schattenmetriken vs. Datei-als-Quelle für Tabellen
• Catalog Deep Dive
• Ein modernes Data Warehouse aufbauen