Azure SQL needs more consideration with NAV

When deploying a solution architecture with Microsoft Dynamics NAV as the ERP of your choice, you already know that the database will be a core feature for your entire architecture.

NAV backend is based on Microsoft SQL Server and when deploying NAV you’ve the choice to (we’re not considering here the SaaS proposition like Dynamics 365):

  1. Install SQL Server on-premise
  2. Install SQL server on an Azure VM
  3. Use Azure SQL Database

With the option 1 and 2, you’ve the responsibilities to manage the infrastructure (scalability, updates, patches and so on) and the database software too (installation, setup and licensing). Obviously, with option 1 you’ve also to manage the hardware, while option 2 is a complete IaaS.

With Azure SQL Database, you can use the “relational database as a service” feature provided by Azure (PaaS). Here, you have a SQL Server database fully managed with scaling capabilities and many other features and options natively offered by the platform like geo-replication or geo-redundancy.

The curious thing that many people don’t know is that Azure SQL Database IS NOT the same as SQL Server. Azure SQL has a different engine totally built and optimized for the cloud and hosted using Azure Service Fabric for the underlying managed infrastructure (are you familiar with concepts like microservices?).

With Azure SQL Database for your NAV deployment in the cloud:

  1. You don’t have to think to the underlying infrastructure of your database.
  2. You don’t have to license SQL Server separately (!!)
  3. You have a complete scalability.
  4. You have automatic index tuning.

Azure SQL Database is very cost-saving option for a classic NAV installation. As an example, I’ve played a bit with the Azure Pricing Calculator in order to define a configuration for the typical NAV installation I see every day on customers around the world:

  • 20-30 users
  • One single database instance for NAV
  • No replication or load balancing

This is the price I can estimate for a configuration like this:

Azure VM for NAV Service Tier:



Azure Managed Disk for a persistent data disk (optional but maybe useful for handling some NAV tasks like file exchange and so on):


Azure SQL Database instance:


Standard Tier offers 99.9% SLA, 35 days backup retention, 1TB database maximum.

The total estimated monthly cost for a server active h 24 x 24 every day is:


Obviously, this is a starting point and from here we can plan more robust architectures with (for example) load balancing between VMs, geo-replication and so on, and all of these architectures will always be cheapest that organizing your on-premise IT infrastructure in order to satisfy all the same features.

For about 300$ you have a cloud infrastructure for your NAV that has 99.9% SLA and it’s completely scalable and fully managed.

Now I hope that Azure SQL will be more considered when planning for a new NAV installation on when transitioning an old installation from on-premise to a cloud environment.


  1. Hi Demiliani,

    We are proposing that scenario for our customers. With 3 Azure SQL databases for:
    – Production
    – Test
    – Development
    In this environment, we concluded that the Azure VM for the NAV Service Tier should have more than 7 GB RAM, at least 14GB. We use at least 1,5 GB per NAV Application Service (prod, test, dev) that makes 4.5 GB and some for the operating system. With 7 GB the memory is always near 100%.
    Do you see any other way to do it?


    1. An Azure VM D2 v2 is a minimum for efficiently handling the NAV Service tier and reducing cost. For more advanced scenarios (and more service tiers on the same machine) Azure VM D3 v2 with 14 GB is better.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s