AI Apps | The .NET Blog

SQL Server 2025 आपकी agent-ready डेटाबेस के रूप में: सुरक्षा, बैकअप और MCP एक ही इंजन में

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल संस्करण के लिए, यहाँ क्लिक करें.

मैंने Aditya Badramraju की Polyglot Tax सीरीज़ को बहुत रुचि से फॉलो किया है। भाग 1-3 ने SQL Server 2025 के लिए एक बहुत मजबूत मामला बनाया था — एक ही engine में JSON, graph, vector और relational डेटा, unified query planner के साथ। भाग 4 उस कहानी को उस हिस्से तक ले जाता है जो वाकई तय करता है कि आप इस architecture पर production में भरोसा करेंगे या नहीं।

संकेत: production कहानी मजबूत है।

सभी Data Models के लिए एक Security Model

Polyglot stacks के साथ यही समस्या है: जब auditor पूछता है, “साबित करो कि Tenant A, Tenant B का डेटा नहीं देख सकता”, तो आपको यह सवाल हर database के लिए अलग-अलग जवाब देना पड़ता है। पाँच databases, पाँच security models, पाँच proofs.

SQL Server 2025 के साथ, आप एक ही Row-Level Security policy परिभाषित करते हैं और वह सभी data models पर लागू हो जाती है:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

उस बिंदु से आगे, हर query — relational joins, JSON path queries, graph traversals, vector similarity searches — अपने आप tenant के हिसाब से filter हो जाती है। engine execution plan में predicate inject कर देता है, storage से कोई data बाहर जाने से पहले। आपके calling code को हर जगह WHERE TenantID = @id लिखने की जरूरत नहीं रहती। आप policy एक बार test करते हैं।

layers आगे भी compose होती हैं: उन columns के लिए Dynamic Data Masking जिन्हें कुछ roles को पूरा value नहीं दिखाना चाहिए, end-to-end encryption के लिए Always Encrypted (DBAs भी data नहीं पढ़ सकते), और stored procedures को permission boundary की तरह इस्तेमाल करना ताकि agents सिर्फ वही call करें जो आपने explicitly expose किया है।

यह architecture का वह हिस्सा है जो compliance-heavy SaaS के लिए सबसे ज्यादा मायने रखता है। एक policy, एक proof.

Unified Backup = Atomic Recovery

एक statement, सभी data models, consistent point in time:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

Polyglot stack में, पाँच databases के लिए point-in-time recovery का मतलब पाँच restore operations को coordinate करना और उम्मीद करना होता है कि timestamps एक-दो सेकंड के भीतर मिल जाएँ। financial data के लिए वह दो सेकंड का फर्क स्वीकार्य नहीं है। एक database, एक transaction log, एक restore — recovery definition से atomic है।

Tamper-Evident Audit Trails के लिए Ledger Tables

regulated industries के लिए, “हमारे पास logs हैं” इतना काफी नहीं है। आपको cryptographic proof चाहिए कि उन logs के साथ छेड़छाड़ नहीं हुई:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

हर insert, update और delete को cryptographically hash करके blockchain-style structure में दर्ज किया जाता है। आप auditor को mathematically साबित कर सकते हैं कि row लिखे जाने के बाद से उसमें छेड़छाड़ नहीं हुई है। polyglot stack में, यह capability आपकी सभी databases में uniformly मौजूद नहीं होती।

MCP Integration: बिना Hand-Coded Middleware के Agents

सीरीज़ यहीं तक जा रही थी: SQL Server 2025 सीधे SQL MCP Server support करता है, जिसका मतलब है कि आपके agents natural-language tool calls के जरिए database को call कर सकते हैं, बिना हर operation के लिए middleware लिखे।

इसे stored procedures as the permission boundary और engine-level Row-Level Security के साथ जोड़ें, और आपके पास ऐसा model है जहाँ:

Agent एक tool call करता है, जैसे “account 12345 के लिए customer context प्राप्त करो”
MCP उसे आपके defined stored procedure में translate करता है
SQL engine tenant isolation और column masking को automatically enforce करता है
Agent को सिर्फ वही data मिलता है जिसे देखने की अनुमति है

कोई middleware layer नहीं। ad-hoc query injection का risk नहीं। authorization agent नहीं, engine संभालता है।

यह .NET Developers के लिए क्यों मायने रखता है

अगर आप .NET services बना रहे हैं और SQL Server आपका primary store है, तो इस सीरीज़ का संदेश है: आपको caching के लिए Redis, relationships के लिए graph database, या embeddings के लिए vector store जोड़ने की जरूरत नहीं है — SQL Server 2025 यह सब संभालता है, और polyglot stack से बेहतर operational consistency के साथ, plus ऐसी unified security जो सच में auditable है।

MCP integration का मतलब है कि आपके Semantic Kernel agents या Microsoft Agent Framework workflows उसी SQL MCP Server के जरिए data tier से interact कर सकते हैं, उसी security guarantees के साथ जिन्हें आप human queries पर भी लागू करेंगे।

समापन

Polyglot Tax सीरीज़ शुरू से अंत तक पढ़ने लायक है। भाग 1-3 query planner की कहानी साबित करते हैं। भाग 4 production की कहानी साबित करता है। .NET developers के लिए जो Azure SQL पर agent-first या AI-augmented applications बना रहे हैं, यह architecture गंभीर विचार के लायक है।

Aditya Badramraju का मूल post: The Polyglot Tax – Part 4.

क्या Copilot को हर दिन 68 मिनट कोड फिर से समझाने में लग रहे हैं? इसका हल है

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित की गई है। मूल संस्करण के लिए, यहाँ क्लिक करें.

क्या आप वह पल जानते हैं जब आपकी Copilot session /compact पर पहुँचती है और agent पूरी तरह भूल जाता है कि आप क्या कर रहे थे? अगले पाँच मिनट आप file structure, failing test, और वे तीन approaches फिर से समझाते हैं जिन्हें आप पहले ही आज़मा चुके हैं। फिर यह सब दोबारा होता है। और फिर दोबारा।

Desi Villanueva ने इसे time किया: 68 minutes per day — सिर्फ़ re-orientation में। कोड लिखने में नहीं। PRs review करने में नहीं। बस AI को वह याद दिलाने में जो वह पहले से जानता था।

असल में ऐसा क्यों होता है, और इसका एक ठोस हल भी है।

कॉन्टेक्स्ट विंडो की झूठी कहानी

आपके agent के बॉक्स पर एक बड़ा नंबर लिखा होता है। 200K tokens. बहुत बड़ा लगता है। व्यवहार में यह एक ceiling है, कोई गारंटी नहीं।

असल गणित यह है:

200K कुल context
लगभग 65K MCP tools के लिए जो startup पर लोड होते हैं (~33%)
लगभग 10K instruction files के लिए, जैसे AGENTS.md या copilot-instructions.md

इससे आपके पास लगभग 125K बचते हैं, उससे पहले कि आप एक शब्द भी लिखें। और हालात और खराब हैं — LLMs context भरते जाने पर शालीनता से degrade नहीं होते। वे लगभग 60% capacity पर दीवार से टकरा जाते हैं। मॉडल 30 turns पहले कही गई बातें खोने लगता है, पहले दिए गए जवाबों का विरोध करता है, और 10 मिनट पहले जिन file names को बहुत आत्मविश्वास से बताया था, उन्हें भी hallucinate करने लगता है। उद्योग इसे “lost in the middle” problem कहता है।

प्रभावी सीमा: 45K tokens उसके बाद quality गिरने लगती है। यानी शायद 20-30 active conversation turns, फिर agent drift करने लगता है। इसी वजह से आप हर 45 मिनट में /compact कर रहे हैं — इसलिए नहीं कि आपने 200K tokens भर दिए, बल्कि इसलिए कि model पहले ही 120K पर खराब होने लगा है।

कॉम्पैक्शन टैक्स

हर /compact आपका flow state छीन लेता है। आप एक deep debugging session में हैं। shared context 30 मिनट से बन रहा था। agent को file structure, failing test, और hypothesis पता है। फिर warning आ जाती है।

अनदेखा करें → agent धीरे-धीरे बेवकूफ होता जाता है, पुरानी state hallucinate करता है
/compact चलाएँ → agent को 30 मिनट की investigation का दो पैराग्राफ़ का सार मिल जाता है

दोनों ही हालात में नुकसान होता है। दोनों ही हालात में आप अपने project को किसी नए join किए हुए employee की तरह दोहरा रहे होते हैं।

कड़वी बात? Memory पहले से मौजूद है। Copilot CLI हर session को ~/.copilot/session-store.db नाम की local SQLite database में लिखता है — हर touched file, हर turn, हर checkpoint. सब disk पर मौजूद है. Agent बस उसे पढ़ नहीं सकता.

auto-memory: एक recall layer, memory system नहीं

auto-memory के पीछे यही मुख्य विचार है: नया memory system मत बनाइए — जो पहले से है, उसके ऊपर एक read-only query layer बनाइए।

pip install auto-memory

करीब 1,900 lines of Python। Zero dependencies. 30 seconds में install.

Context को grep results से भरने के बजाय, आप agent को उस चीज़ तक surgical access देते हैं जो सच में मायने रखती है:

ऑपरेशन	Tokens	आपको क्या मिलता है
`grep -r "auth" src/`	~5,000–10,000	500 results, जिनमें से ज़्यादातर irrelevant हैं
`find . -name "*.py"`	~2,000	सभी Python files, बिना context के
Agent re-orientation	~2,000	आप उसे वह समझा रहे हैं जो उसे पहले से पता होना चाहिए
`auto-memory files --json --limit 10`	~50	कल आपने जिन 10 files पर काम किया था

यह 200x improvement है। Agent archaeology dig छोड़ देता है और सीधे उस चीज़ पर पहुँच जाता है जो मायने रखती है।

Recommended flow: जब आप 50-70% context usage के पास पहुँचें, /clear चलाएँ और फिर prompt करें: “उन पिछली sessions की समीक्षा करो जिनमें हमने विषय X पर बात की थी”। Blind searches पर 12K tokens जलाने के बजाय, auto-memory relevant context को 50 में निकाल लेता है।

यह .NET developers के लिए क्यों मायने रखता है

अगर आप GitHub Copilot CLI का इस्तेमाल .NET work के लिए कर रहे हैं — services scaffold करना, EF Core queries debug करना, Blazor components पर iterate करना — तो context rot की समस्या उतनी ही तेज़ी से आती है। Multiple projects, shared libraries, और deep call chains वाली complex solutions वही codebases हैं जहाँ agent सबसे जल्दी track खो देता है।

Install guide बताती है कि Copilot CLI को इसकी ओर कैसे point करना है। यह एक one-time setup है।

सच कहें तो? 68 minutes a day वापस पाना कोई छोटा quality-of-life tweak नहीं है। यह लगभग 6 hours a week है।

समापन

Context rot एक वास्तविक architectural constraint है, कोई ऐसा bug नहीं जो बस patch होकर ठीक हो जाएगा। auto-memory आपका agent expensive, noisy re-exploration करने के बजाय cheap और precise recall mechanism देकर इस सीमा को bypass करता है। अगर आप GitHub Copilot CLI के साथ serious AI-assisted development कर रहे हैं, तो 30-second install वाकई क़ीमती है।

देखिए: GitHub पर auto-memory. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.