标签：#platformengineering

If you manage PostgreSQL databases across multiple environments, you've probably done this: SSH to the DB host (or connect via psql ) Run CREATE USER jsmith CONNECTION LIMIT 20 PASSWORD '...' Slack the password to the developer Forget to log it anywhere Repeat for every environment, every onboarding, every access request It's tedious, error-prone, and leaves zero audit trail. Here's a better way. What I Built pg-user-api is a lightweight Flask REST API that wraps PostgreSQL user provisioning in clean HTTP endpoints. You register your databases once in a SQLite inventory, then any tooling — CI pipelines, internal portals, Ansible playbooks, or a plain curl — can create and manage users across environments without ever touching psql . GitHub: pcraavi/PostgreSQL-user-creation-API The Problem It Solves In teams that span dev, QA, UAT, and prod, you end up with different patterns of users: App service accounts — named after the host/port combo ( web01_8080 ) Kubernetes workload accounts — named after env prefix + farm ( dv_gearservice ) Individual dev/QA accounts — low connection limits, scoped to non-prod Read-only analyst accounts — prod only, no DDL DBA accounts — CREATEDB CREATEROLE LOGIN , rarely provisioned Each type has different CONNECTION LIMIT values, privilege levels, and naming conventions. Encoding these patterns in an API means the rules are consistent, repeatable, and auditable. Architecture The project is intentionally small — five Python files and a requirements list: pg_user_api/ ├── app.py # Flask app — all endpoints ├── auth.py # HTTP Basic Auth (constant-time compare) ├── database.py # SQLite registry + audit log ├── notifications.py # Notification stubs (Webex / Slack / Email) ├── seed_db.py # One-time setup: creates DB + sample records └── requirements.txt Two credential pairs, clearly separated: PG_API_USER / PG_API_PASS — who can call this API (your team/tooling) PG_ADMIN_USER / PG_ADMIN_PASS — the PostgreSQL DBA role that executes DDL The DBA cr

Platform team sprint planning in 2026 begins with budget allocation, not architecture review. The first question is no longer "what do we need to build?" — it's "what can we afford to run?" This is not FinOps adoption. This is authority displacement. The platform team became a finance team because the control plane for infrastructure decisions migrated from architecture governance to budget governance. Cost constraints don't inform architectural decisions anymore — they dictate them. And when financial systems gain veto authority over technical systems, resilience becomes the variable that adjusts. Platform team cost governance is now the primary control surface. Architecture is secondary. How We Got Here The timeline is sharper than most organizations admit. 2018–2022 was the cloud adoption phase. Platform teams built for scale. Multi-region resilience was standard. Observability was deep. Auto-scaling was elastic. Architectural requirements shaped cost models. The budget followed the design. 2023–2024 brought FinOps as a cost visibility layer. Teams could finally see where money was going. Dashboards got built. Anomaly detection got configured. Attribution models got refined. But visibility was still separate from authority. The FinOps team reported. The platform team decided. 2025–2026 is when cost governance moved from reporting to gating. The turning point: platform teams stopped asking "can we build this?" and started asking "can we afford this?" Engineering roadmaps became cost roadmaps. Feature requests now come with budget allocation approvals. Architecture reviews now include CFO sign-off gates. This shift introduced Budget-Normalized Architecture — systems designed around predictable monthly spend targets instead of operational resilience targets. The architecture no longer optimizes for failure domains, latency requirements, or recovery objectives. It optimizes for staying under the cost ceiling. Cost governance expanded because engineering governance fa