Understanding Navision’s Dual‑Database Landscape
Microsoft Dynamics NAV, once known simply as Navision, has evolved into a versatile platform that serves enterprises in both Europe and North America. At its core, the system is designed to handle the complex needs of manufacturing, distribution, and service organizations. One of the most significant decisions an IT specialist faces when deploying or upgrading NAV is choosing the underlying database. NAV can run on its proprietary C/SIDE database or on Microsoft SQL Server. Each option brings a distinct set of capabilities, trade‑offs, and administrative requirements.
The proprietary C/SIDE database, developed by the Danish company Navision Software, was crafted to work hand‑in‑hand with the Navision application. It emphasizes tight coupling between the data layer and business logic, ensuring that transactions are handled consistently and that the user interface remains responsive even under heavy load. Over the years, NAV has retained this architecture because it delivers a predictable, reliable experience in environments where downtime is costly and system integrity is paramount.
Conversely, SQL Server offers a mature, enterprise‑grade relational database that supports massive data volumes, advanced analytics, and integration with a broad ecosystem of Microsoft products. The platform provides robust backup and restore capabilities, replication, high‑availability features, and a powerful set of tools for reporting and business intelligence. These strengths make SQL Server attractive for organizations that need to scale beyond what the legacy C/SIDE engine can comfortably handle or that require deep integration with other Microsoft technologies such as Power BI, Azure, or SharePoint.
When deciding between these two engines, IT leaders must weigh factors such as data volume, existing infrastructure, skill sets within their teams, and the strategic direction of the business. The decision is not simply a technical one; it influences the entire lifecycle of the NAV implementation - from deployment and day‑to‑day maintenance to future expansion and integration. The subsequent sections break down the core considerations that shape this choice and provide a framework for evaluating each option in the context of your organization’s goals.
The Enduring Edge of C/SIDE
For many years, Navision’s C/SIDE database has been a cornerstone of the platform’s identity. Its architecture reflects a clear philosophy: keep the database logic inside the same ecosystem that runs the application. This tight coupling offers several tangible benefits that resonate with companies that have historically relied on Navision for mission‑critical processes.
First, the built‑in transaction integrity of C/SIDE means that every data modification is automatically wrapped in a transaction boundary that ensures either all changes are committed or none are applied. The system guarantees that the database remains in a consistent state even when a power failure or a sudden crash occurs. In practical terms, a plant floor manager can run a batch job during a blackout, and when power returns, the system will be exactly as it was before the outage. This level of reliability has been a selling point for manufacturing firms where data loss can translate into production downtime and financial loss.
Second, the database schema is tightly integrated with the NAV application logic. Developers can use the C/SIDE development environment to create tables, fields, and indices that align precisely with the object structure of NAV. Because the database engine is designed to understand NAV’s conventions, performance tuning often boils down to configuring page sizes and page pools rather than writing complex SQL scripts. For organizations that prioritize ease of development and maintainability, this direct alignment reduces the learning curve and speeds up the delivery of customizations.
Third, the C/SIDE database is intentionally lightweight compared to a full‑blown relational engine. It does not expose the same range of features that SQL Server offers, but this simplicity can be an advantage for environments that do not need advanced analytics or data warehousing. The smaller footprint also translates into faster backup and restore times, which can be critical for companies that operate on tight maintenance windows or have limited storage capacity.
However, the proprietary nature of C/SIDE imposes constraints. It does not support the extensive set of data types, indexing strategies, or foreign‑key enforcement mechanisms available in SQL Server. For instance, if your organization plans to implement a complex data model that includes multi‑table relationships, array‑like structures, or advanced search capabilities, you may hit the limits of what C/SIDE can comfortably handle. Likewise, the lack of native support for features like columnstore indexes or in‑database analytics means that companies aiming to derive insights directly from NAV data might need to build additional layers on top of the C/SIDE engine.
From an administrative perspective, managing a C/SIDE database requires a different skill set than administering SQL Server. While C/SIDE provides tools for monitoring and maintenance, they are less granular than SQL Server’s Management Studio or PowerShell cmdlets. For teams that already have expertise in SQL Server administration, learning the intricacies of C/SIDE might introduce a learning curve and potential gaps in knowledge coverage.
Ultimately, the choice to stick with C/SIDE comes down to valuing stability, developer familiarity, and a lean architecture. If your organization has a long‑standing Navision deployment, limited data volume, and a workforce that is comfortable with the legacy environment, C/SIDE remains a viable, low‑risk option that aligns closely with NAV’s original design goals.
SQL Server: Scale, Integration, and Modern Needs
Microsoft SQL Server has become the default database choice for many modern NAV deployments, especially for businesses that demand higher scalability, richer analytics, and tighter integration with other Microsoft products. The platform’s robust feature set makes it well suited for handling large data volumes and complex transaction workloads that exceed the capacity of C/SIDE.
One of the most compelling arguments for SQL Server is its ability to manage petabyte‑scale datasets while maintaining performance. The engine supports sharding, partitioning, and parallel execution of queries, which together allow businesses to store millions of records across multiple tables without sacrificing query speed. For manufacturing enterprises that generate terabytes of sensor data, inventory logs, and sales transactions, SQL Server provides the infrastructure to store and retrieve that data efficiently.
Beyond sheer storage capacity, SQL Server offers advanced indexing techniques such as columnstore and filtered indexes. These options significantly accelerate analytical queries, making it easier to produce real‑time dashboards or perform complex aggregations on large datasets. Coupled with SQL Server’s integration with Power BI and Excel, organizations can build dynamic reporting layers that feed directly from NAV tables, bypassing the need for intermediary data warehouses.
Security and compliance are another critical consideration. SQL Server’s built‑in encryption, row‑level security, and transparent data encryption capabilities allow businesses to meet stringent regulatory requirements such as GDPR or PCI‑DSS. The platform’s comprehensive audit trail and fine‑grained access controls provide a level of auditability that is difficult to replicate in a proprietary database engine.
From a developer standpoint, SQL Server supports stored procedures, triggers, and views that can encapsulate business logic within the database. This capability can reduce application complexity by moving repetitive validation or calculation logic into the data layer. Moreover, the platform’s compatibility with Entity Framework and LINQ means developers can write object‑oriented code that interacts seamlessly with NAV data.
Administrators who are already familiar with SQL Server find that deploying NAV on this platform aligns with existing toolsets and skill sets. Backup and recovery can leverage SQL Server’s built‑in backup strategies, including differential backups, log shipping, and always‑on availability groups. Monitoring is supported through SQL Server Management Studio, Azure Monitor, and third‑party tools, giving IT staff a familiar set of dashboards and alerts.
Integration with other Microsoft services is a natural fit. Whether you need to expose NAV data to a Power Apps canvas app, feed data into Azure Synapse for big data analytics, or synchronize records with Dynamics 365 Sales, SQL Server provides native connectors and ODBC drivers that simplify the process. In contrast, the C/SIDE database requires additional adapters or custom code to achieve similar interoperability.
Choosing SQL Server also positions your NAV implementation for future growth. As businesses move towards hybrid or cloud‑native architectures, SQL Server can run on-premises, in Azure SQL Managed Instance, or even on Azure SQL Database. This flexibility enables a gradual migration path from on‑premises to cloud‑based solutions without overhauling the entire application stack.
Nonetheless, the decision to switch to SQL Server is not trivial. It demands a migration effort, potential retraining for developers, and careful planning to ensure that custom NAV objects and third‑party extensions remain compatible. The initial learning curve and migration cost must be weighed against the long‑term benefits of scalability, integration, and modern analytics capabilities.
Decision Checklist for IT Leaders
When evaluating which database engine to pair with NAV, IT specialists need a structured approach that accounts for technical requirements, business goals, and operational realities. The following framework helps organize the decision process into clear, actionable steps.
1. Map your current data footprint. Estimate the total volume of records in your NAV database and project growth over the next 3–5 years. If you anticipate millions of records or need to store large binary objects, SQL Server’s scalability may become a decisive factor.
2. Identify critical transaction patterns. Determine how many concurrent users and transactions you expect during peak periods. C/SIDE handles moderate concurrency well, but if you foresee heavy simultaneous writes or complex multi‑table updates, SQL Server’s isolation levels and locking mechanisms can provide stronger guarantees.
3. Assess your reporting and analytics strategy. If you plan to generate dashboards, run ad‑hoc queries, or integrate with Power BI, the built‑in analytics capabilities of SQL Server will simplify development and reduce latency. For static reporting, C/SIDE with ODBC can suffice, but you may need additional layers for advanced visualizations.
4. Examine your existing skill set. If your team already manages SQL Server, the transition to a NAV deployment on SQL Server will be smoother. Conversely, if you lack SQL Server expertise, maintaining a C/SIDE database might keep operational risk lower until the necessary skills are acquired.
5. Consider compliance and security requirements. If your industry demands stringent audit trails, encryption, and access controls, SQL Server’s mature security features can help meet those obligations without extensive custom development.
6. Review third‑party integration needs. For organizations that rely on external applications - such as ERP extensions, business intelligence tools, or custom web services - SQL Server’s ODBC and JDBC drivers simplify connectivity. C/SIDE may require specialized adapters that can increase maintenance overhead.
7. Evaluate migration costs and timelines. A move from C/SIDE to SQL Server involves data export/import, object mapping, and potential re‑implementation of custom code. Calculate the effort required against the projected benefits and schedule the migration during a maintenance window that minimizes business disruption.
8. Define a support and maintenance plan. Whether you choose C/SIDE or SQL Server, outline how database backups, patching, and monitoring will be handled. SQL Server offers automated tools for backup scheduling and failover clustering, which can reduce manual oversight.
By systematically addressing each of these areas, IT leaders can craft a database strategy that aligns with their organization’s operational needs and long‑term vision. The decision is rarely about choosing one technology over another; it’s about selecting the engine that best fits your current environment while enabling future growth and integration.
Integrating Reporting, Analytics, and External Applications
Once the database engine is chosen, the next phase focuses on extending NAV’s capabilities beyond transactional processing. Modern businesses expect real‑time insights, dynamic dashboards, and seamless data exchange with other applications. The database platform you select dictates the level of integration complexity and the performance of analytics workloads.
With a SQL Server back‑end, you can take advantage of native support for views, stored procedures, and materialized aggregates. These constructs let you expose curated data sets that are pre‑aggregated for reporting, reducing the load on the main transaction engine. Coupled with SQL Server Analysis Services (SSAS), you can build multidimensional cubes that enable fast slicing and dicing of financial data, inventory levels, or production metrics. Integrating these cubes with Power BI gives end‑users an intuitive way to explore trends, forecast demand, and spot bottlenecks.
Moreover, SQL Server’s integration services (SSIS) provide robust ETL pipelines that can pull data from NAV tables, transform it, and load it into data warehouses or data lakes. For organizations that already use Azure Synapse or Azure Data Factory, this integration is straightforward thanks to built‑in connectors. The result is a single source of truth that powers analytics across the enterprise.
In contrast, the C/SIDE database relies on ODBC or front‑end adapters for reporting. While you can build Crystal Reports or SSRS reports that query C/SIDE via ODBC, performance may suffer under heavy load. Additionally, creating complex aggregations or OLAP cubes typically requires external tools or custom code, which can increase maintenance overhead.
When exposing NAV data to other applications, the choice of database again influences the technology stack. SQL Server’s OLE DB and JDBC drivers are well supported across a wide range of development frameworks, enabling quick integration with web services, mobile apps, or third‑party ERPs. With C/SIDE, you may need to develop or procure specific connectors, and the lack of standard drivers can hinder rapid development.
Another important aspect is the use of APIs. NAV provides a Web Services framework that can expose business objects over SOAP or REST. When running on SQL Server, these services can leverage database triggers or stored procedures to enforce business rules, ensuring that data integrity is maintained even when external applications modify records.
Security remains paramount during integration. With SQL Server, you can enforce row‑level security to restrict data exposure based on user roles, a feature not available in C/SIDE. Additionally, you can leverage Azure Active Directory or on‑premises Active Directory to manage authentication for services that access NAV data.
Finally, consider future‑proofing your architecture. If you anticipate moving portions of your analytics workload to the cloud, SQL Server’s compatibility with Azure services offers a smooth transition. You can migrate your NAV database to Azure SQL Managed Instance or Azure SQL Database, and continue to use SSAS, SSIS, and Power BI without significant code changes.
In summary, the database platform you pick sets the foundation for reporting, analytics, and integration. SQL Server provides a comprehensive, scalable, and secure environment that aligns with modern business intelligence practices, while C/SIDE offers a simpler, more tightly coupled approach suitable for organizations with moderate data needs and limited integration requirements. Aligning your choice with your long‑term data strategy ensures that Navision remains a reliable backbone for your enterprise processes while empowering stakeholders with the insights they need to drive growth.
For more information about deploying Navision with SQL Server or to discuss your specific scenario, reach out to Robert Horowitz, a certified Navision specialist with Alba Spectrum Technologies. You can email him at welcome@albaspectrum.com or visit
Tags
No comments yet. Be the first to comment!