SQL Server 2008 shipped Policy-Based Management. PBM let you define rules for naming conventions, index requirements, and security settings, then evaluate on demand or schedule compliance checks. I loved the idea of defining standards once and enforcing them everywhere.
While so promising, it never took off. Like so many ideas, it was correct but too early.
Why am I looking back to this? Agents.
Agents are building products and talking to each other now. They are building apps. Whether we like it or not, they are writing database schemas and queries. Current databases assume human operators with human judgment and review cycles. Someone with context catching the obvious mistakes.
When the next Y Combinator batch drops, I would like to see a company in the agentic-first database category. I mean agent-first databases built from scratch for a world where agents are the primary authors, not databases with agent connectors bolted on.
What would that mean?
Built-in curiosity. On setup, these agentic-first databases need to first understand who is installing them, their policies, use cases, rules, and culture.
Adaptive policy-building. Action reveals character (it isn’t what we say but what we do). These database systems need to also learn based on activity and respond and adapt policies accordingly.
Structural enforcement over advisory guidance. Policies block violations, not just report them.
Cost-aware schema validation. For example, before accepting DDL, simulate query patterns and flag designs that will require table scans on large tables.
Mandatory rollback paths. Every schema change includes its reversal.
Audit lineage by default. Track which agent proposed which change and what context it had.
Diverse opinions. Spawn the full set of agent roles as gates. Security \ storage \ network experts. Leverage different foundation models to invoke these roles. We need adversarial reviews so we don’t merrily run off that cliff.
Human gates for destructive operations. Drops, truncates, and permission escalations require human approval with no override flag.
There is so much more - and you could push this down to the deep internals (query optimizer, storage engine). Ideally everything built here has a human DBA fleet manager, but this will be a corporate culture character test and I’m not bullish on that.
PBM had the right instinct in 2008. Maybe 20 years later we’ll see a revival.
When you say PBM was correct but too early, I'd qualify that SQL Server 2008's idea of PBM was correct, but the implementation certainly was not. The checks were done post-execution - like, after the index was already built, the whole thing would be rolled back for having the wrong name.
Plus the real things we needed PBM for in the field (like backups and corruption checking) didn't ship. I really don't care what the index's name is - I care that it's backed up and protected. Microsoft went after the low-hanging fruit with PBM, but that fruit was low-hanging because nobody wanted to eat it.