India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Azure SQL, SQL Managed Instance, Cosmos DB & PostgreSQL Services
Azure managed databases are Microsoft's platform-as-a-service data engines: Azure SQL Database including Hyperscale, Azure SQL Managed Instance, Azure Cosmos DB and Azure Database for PostgreSQL Flexible Server. NTSPL migrates SQL Server estates to Managed Instance or Hyperscale and designs Cosmos DB and PostgreSQL for Indian lenders, retailers and manufacturers, with zone-redundant HA, failover to South India and Hybrid Benefit licensing.
Microsoft Azure services in scope
The Problem Azure SQL Managed Instance and Azure SQL Database (General Purpose, Business Critical) Solve
Most Indian mid-market data estates run SQL Server 2012 to 2017 on a single physical host or a two-node failover cluster, with one or two DBAs handling patches, index maintenance, backups and the occasional 2 am restore. Licensing is per core, so the hardware cannot be resized without a licence true-up. The database problem in Azure is choosing the right engine and tier: SQL Managed Instance for instance-level features like SQL Agent and cross-database queries, Azure SQL Database or Hyperscale for single-database apps that grow fast, Cosmos DB for globally distributed or schema-flexible data, and PostgreSQL for open-source stacks.
NTSPL begins with an Azure Migrate SQL assessment for compatibility blockers and right-sizing, then reads the application code for cross-database joins, linked servers, CLR and SQL Agent jobs that decide between Managed Instance and SQL Database. For Cosmos DB, we model partition keys from real access patterns before writing a single document, because the key cannot be changed in place. Cutover uses the Managed Instance link or Database Migration Service in online mode so production downtime is measured in minutes.
When to Choose Azure SQL, Managed Instance, Cosmos DB or PostgreSQL Flexible Server
Signals that point to databases on Microsoft Azure
- SQL Server 2012, 2014 or 2016 instances are at or past end of extended support and the hardware under them is out of warranty.
- DBAs spend more than a day a week on patching, backup verification and index jobs instead of query and schema work.
- A single SQL database has passed 4 TB and backups or DBCC checks no longer finish inside the maintenance window.
- Reporting queries from BI tools are blocking OLTP transactions during business hours.
- A customer-facing app needs predictable sub-10 ms reads at millions of requests a day, with a schema that changes every release.
When a different approach is better
- Databases relying on SQL Server features not available in Managed Instance, such as certain file-system access or OS-level customization: SQL Server on Azure Virtual Machines keeps full OS control.
- Relational, join-heavy reporting workloads proposed for Cosmos DB: cross-partition joins are not supported, so Azure SQL Database or PostgreSQL is the better engine.
- Analytics over many terabytes of historical data with large scans: Microsoft Fabric or Azure Databricks handles columnar analytics better than an OLTP engine.
Azure Database Engines: SQL Database, Hyperscale, SQL Managed Instance, Cosmos DB and PostgreSQL
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Azure SQL Managed Instance | Runs a near-fully compatible SQL Server engine as a managed instance inside a customer VNet subnet, with SQL Agent, cross-database queries, Service Broker and CLR. | The application uses instance-scoped features or multiple databases that query each other, and rewriting is not an option. |
| Azure SQL Database (General Purpose, Business Critical) | Provides a single managed database or elastic pool with automatic patching, backups and built-in HA, in provisioned or serverless compute. | A modern application owns one database and does not depend on SQL Agent or cross-database references. |
| Azure SQL Database Hyperscale | Separates compute from a distributed page-server storage layer, supporting databases up to 128 TB with snapshot-based backups and named read replicas. | A single database is past 4 TB or growing more than 1 TB a year, or reporting load needs to be isolated on its own replicas. |
| Azure Cosmos DB for NoSQL | Stores JSON documents partitioned by a chosen key across physical partitions, with throughput in request units per second, five consistency levels and a change feed. | Access is by key with single-digit-millisecond reads, the schema varies by record, or the app needs multi-region writes. |
| Azure Database for PostgreSQL Flexible Server | Runs community PostgreSQL with zone-redundant HA, built-in PgBouncer, read replicas and the ability to stop compute when idle. | The application is built on PostgreSQL or needs extensions such as PostGIS or pgvector without SQL Server licensing. |
| Azure Database Migration Service and Managed Instance link | Moves databases online from SQL Server to Azure SQL targets; the MI link replicates continuously from SQL Server 2016 and later using distributed availability groups. | The cutover window is under an hour and the source database is too large to back up and restore within it. |
Zone-redundant SQL Managed Instance with Hyperscale and Cosmos DB tiers
Zone-redundant SQL Managed Instance with Hyperscale and Cosmos DB tiers
Application servers connect over private endpoints or VNet-local endpoints to a Business Critical SQL Managed Instance in Central India, whose failover group keeps a geo-secondary in South India. High-growth single databases sit on Hyperscale with a named replica for reporting, and key-value workloads use Cosmos DB with change feed into downstream services.
Select any component
Zone-redundant SQL Managed Instance with Hyperscale and Cosmos DB tiers: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 5-step primary path.
Azure Database Engineering Decisions: Engine Fit, Service Tier, Partition Keys and Failover Groups
Managed Instance or SQL Database
Inventory instance-scoped dependencies first: SQL Agent jobs, linked servers, cross-database queries, Database Mail, Service Broker and CLR assemblies. Any of these points to Managed Instance; rewriting them for SQL Database rarely pays back for a packaged application. Choose SQL Database for apps you own that use one database, where elastic pools or serverless can cut cost across many small tenants. Use SQL Server on Azure VMs only where vendor certification or OS-level access makes PaaS impossible.
Service tier: General Purpose, Business Critical or Hyperscale
General Purpose uses remote storage with higher I/O latency and fits most line-of-business apps. Business Critical uses local SSD with an Always On replica set, giving low-latency I/O, a free readable secondary and faster failover; choose it when log write latency or read scale matters. Hyperscale suits databases beyond 4 TB or with unpredictable growth, with near-instant backups and restores regardless of size, and named replicas for isolated reporting.
Cosmos DB partition key and throughput model
Pick a partition key with high cardinality that appears in most queries, such as customerId or memberId, so reads are single-partition. Each logical partition is limited to 20 GB, so tenant or store keys can overflow; hierarchical partition keys solve that. Use autoscale when traffic varies more than 3x across the day, since it scales between 10 percent of the maximum and the maximum; use serverless for development or low, spiky traffic; use provisioned standard throughput for flat 24x7 load.
High availability and DR across Indian regions
Enable zone redundancy in Central India for Business Critical, Hyperscale and PostgreSQL Flexible Server so a zone loss causes only an automatic failover. For regional DR, use auto-failover groups for SQL Managed Instance and SQL Database to South India, with a grace period set to the business's tolerance for data loss. For Cosmos DB, add South India as a read region and enable service-managed failover; enable multi-region writes only when the app handles conflicts.
Migration method and cutover
For SQL Server 2016 and later to Managed Instance, the Managed Instance link replicates continuously and lets you cut over in minutes; it also allows failback. For older versions, use Database Migration Service in online mode with log shipping from backups on Blob Storage. Offline backup and restore is acceptable for databases under about 200 GB with a weekend window. Always run application regression tests against a restored copy before scheduling cutover.
How NTSPL Migrates SQL Server to Managed Instance and Builds Cosmos DB Workloads
SQL assessment and dependency scan
Run Azure Migrate SQL assessment and script out SQL Agent jobs, linked servers, logins and cross-database references to choose Managed Instance or SQL Database per database.
Managed Instance subnet and failover group
Deploy Managed Instance in a delegated subnet with NSG and route table, create the South India secondary and configure the failover group listener.
Online replication via MI link or DMS
Seed and continuously replicate production databases, then validate row counts, Query Store baselines and job outcomes on the target.
Cosmos DB modelling and load test
Design containers and partition keys from access patterns, replay production-like traffic and set autoscale maximums from measured RU consumption.
Cutover and connection switch
Freeze writes, complete the final sync, repoint connection strings to the listener or new endpoint and run smoke tests within the agreed window.
Licence, reservation and tuning review
Apply Hybrid Benefit, purchase reserved capacity after 30-60 days and tune the top queries flagged by Query Store regressions.
What you receive
Securing Azure Databases: Entra-Only Auth, TDE with CMK, Private Endpoints and Ledger
Database risk concentrates in credentials, network exposure and privileged access to sensitive columns. NTSPL enforces Entra-only authentication so no SQL logins exist to be leaked, places Managed Instance in a dedicated subnet and SQL Database behind private endpoints, encrypts with TDE using customer-managed keys, and uses Always Encrypted or dynamic data masking for Aadhaar-linked or card fields so DBAs cannot read them in clear text.
- Microsoft Entra-only authentication, removing SQL logins and their password reuse risk
- Always Encrypted with secure enclaves for columns holding identity or account numbers
- Ledger tables in Azure SQL for tamper-evident history of loan or traceability records
- Defender for SQL threat detection for SQL injection and anomalous access alerts
- Cosmos DB role-based data plane access with local key authentication disabled
Azure Database Pricing Levers: vCores, Hybrid Benefit, Reserved Capacity and Cosmos DB RU/s
Azure SQL and Managed Instance bill per vCore-hour by tier and hardware generation, plus storage and long-term backup retention; the SQL licence share disappears under Hybrid Benefit. Hyperscale bills compute and storage separately. Cosmos DB bills provisioned or autoscale RU/s per hour, or per million RUs on serverless, plus storage per GB. PostgreSQL bills compute and storage with no licence component.
- Azure Hybrid Benefit for SQL Managed Instance and SQL Database vCore tiers using existing SQL Server licences with SA
- 3-year reserved capacity for SQL Managed Instance and Cosmos DB provisioned throughput
- Serverless SQL Database with auto-pause for development and low-usage databases
- Cosmos DB indexing policy that excludes unused paths, cutting write RU charges
- PostgreSQL Flexible Server stop/start for non-production servers outside working hours
Azure SQL Managed Instance vs Azure SQL Database vs SQL Server on Azure VM: which should I migrate to?
Decide on four criteria. Compatibility: Managed Instance supports nearly all SQL Server engine features including SQL Agent, cross-database queries and linked servers; SQL Database is scoped to one database; a VM supports everything, including OS access. Operational load: Managed Instance and SQL Database handle patching, backups and HA; on a VM you manage them. Scale: SQL Database Hyperscale reaches 128 TB per database and scales reads with named replicas. Cost: all three accept Hybrid Benefit, but PaaS removes cluster and backup infrastructure costs. NTSPL rule: packaged multi-database apps go to Managed Instance; owned single-database apps go to SQL Database or Hyperscale; only vendor-locked or OS-dependent workloads stay on VMs.
Key facts about databases on Microsoft Azure
Databases on Microsoft Azure in Practice
3 databases scenarios from Microfinance (NBFC-MFI), Apparel retail, Electronics manufacturing: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Microfinance lender moves loan SQL Server to Managed Instance in an 18-minute cutover
Apparel retailer serves 6 million loyalty members from Cosmos DB at 8 ms p99 reads
Electronics maker scales PCB traceability to 22 TB on Azure SQL Hyperscale
Real-estate developer handles 40x launch-day traffic on its booking portal
ERP vendor turns single-tenant installs into multi-tenant SaaS on AKS Automatic
Databases on Microsoft Azure: Frequently Asked Questions
How is Azure SQL Managed Instance priced?
Managed Instance is billed per vCore-hour based on service tier and hardware, plus reserved storage beyond the included amount and backup storage beyond the free allocation. With Azure Hybrid Benefit, you pay only the base compute rate using your SQL Server licences with Software Assurance. Reserved capacity for one or three years lowers compute further. NTSPL builds an INR comparison against your current SQL Server licence and hardware costs.
How much downtime does migrating SQL Server to Managed Instance need?
With the Managed Instance link or online migration through Database Migration Service, downtime is typically limited to the final cutover, often 10-30 minutes, while connection strings are switched and the last transactions replicate. The link requires SQL Server 2016 or later. NTSPL rehearses the cutover on a copy and times it before the production weekend.
Can our databases stay in India for RBI or DPDP Act compliance?
Yes. Azure SQL, Managed Instance, Cosmos DB and PostgreSQL Flexible Server can be deployed in Central India, South India and West India, with failover groups or read regions kept within India. Backup storage redundancy can be set to keep copies in-region. NTSPL documents data locations for RBI IT outsourcing reviews and DPDP Act data-processing records.
What is a Cosmos DB request unit and how do we estimate RU/s?
A request unit is a normalized measure of the CPU, memory and IO a database operation uses; a 1 KB point read by id and partition key costs about 1 RU, while writes and queries cost more. Estimate by running representative operations and reading the request charge header. NTSPL benchmarks real queries and indexing policy before setting autoscale maximums.
When should we choose Hyperscale over Business Critical?
Choose Hyperscale when the database is large or growing fast, when backup and restore times are a problem, or when you need several read replicas for reporting. Choose Business Critical when you need the lowest write latency from local SSD storage and a single built-in readable secondary is enough. Many estates use both for different applications.
Do we still need a DBA after moving to Azure managed databases?
Yes, but the work changes. Patching, backups, HA configuration and storage management are handled by the platform, so DBA time moves to query tuning with Query Store, index design, schema changes, cost review and security reviews. Most mid-size firms find one DBA can cover two to three times as many databases after migration.