Comparing and contrasting Windows Azure Table Storage and Windows Azure SQL Database
This article compares the two structured storage services supported by Windows Azure: Windows Azure Table Storage and Windows Azure SQL Database, formerly known as SQL Azure. The purpose of this article is to compare these technologies so that you can understand their general and various characteristics. This comparison will help you make a more informed decision about which technology will be better suited for the implementation of your scenario.
When it comes to persistent data storage in Windows Azure, there are two options for cloud technologies: Windows Azure SQL Database and Windows Azure Table Storage.
The Windows Azure SQL Database is a relational database service that extends the core functionality of SQL Server to the cloud. With SQL Database, you can deploy relational database solutions in the cloud, and the benefits of this approach include managed infrastructure, high availability, scalability, a familiar development model, and various frameworks and data access utilities - everything looks like what we see with traditional SQL Server environment. The SQL Database also offers real-time migration, export, and synchronization capabilities of local SQL Server databases with databases in Windows Azure SQL (using SQL Data Sync ).
Windows Azure Table Storage is a fault-tolerant, ISO 27001 certified NoSQL storage service (key-value) that can be useful for applications that store large amounts of non-relational data for which additional structures are needed. This service provides key-based access to data that does not have a schema. Moreover, if you store structured data without a schema, you cannot create relationships between the data.
')
Despite the tangible differences, both services are highly available managed services, for which 99.9% monthly SLA is provided.
Like SQL Database, Windows Azure Table Storage stores structured data. The main difference between the two services is that the SQL Database is a relational database management system based on the SQL Server engine and is built on standard principles and relational basics, thus providing features such as Transact-SQL queries, ACID transactions, stored procedures performed on the server side.
Windows Azure Table Storage is a flexible key-value entity storage that allows you to quickly create a cloud-based application without locking the application's data model to a specific set of schemas. This service is not a relational data repository and does not provide such capabilities for managing relational data as SQL Database (for example, join-s and stored procedures). Windows Azure Table Storage has limited support for server-side queries, but has transaction functions. In addition, different records within the same table can have a different structure, and this approach in Windows Azure Table Storage allows you to efficiently store and operate with simple relational data.
If your application stores and operates with large amounts of data for which there is no need to use relational functions, Windows Azure Table Storage may be a more appropriate option. If your application needs to handle datasets combined with any schema, SQL Database looks like a better option than Windows Azure Table Storage. There are several other factors to consider before deciding whether to use SQL Database or Windows Azure Table Storage, some of which are listed below.
Considerations for choosing technology
When determining a data storage technology that is appropriate for a particular solution, the architect and the developer should consider the following recommendations:
Consider using Windows Azure Table Storage when:
· Your application should store large amounts of data (for example, many terabytes) in low-cost storage.
· Your application stores and operates with large data arrays that do not have complex relational relations, for which you need to use server-side join-s, secondary indexes, or some kind of complex logic running on the server side.
· Your application needs a flexible data scheme for storing objects that are heterogeneous in their scheme, the structure of which is difficult to determine at the design stage.
· Your business needs data storage capabilities in case of catastrophic situations using geographic spacing. Windows Azure tables are geographically replicated across two datacenters located a few hundred miles from each other, but on the same continent, which provides additional confidence in data integrity in the event of a disaster.
· You need to store more than 150 GB of data without using sharding or partitioning.
· You need a high level of scaling without manual sharding data.
Consider using Windows Azure SQL Database when:
· Your application performs data processing that has a high degree of structuredness with relationships and schemas.
· Your data is essentially relational and needs to implement the key principles of the software model of relational data to ensure data integrity through data uniqueness rules, constraints, and various types of keys.
· The amount of your data may not exceed 150 Gb per dedicated storage unit (database), however you can partition your data into several databases if this limit is exceeded, which may be changed in the future.
· Your existing data-oriented applications are already using SQL Server, but you need access to cloud storage using existing frameworks and the ability to transparently migrate between the local infrastructure and Windows Azure.
· You plan to use T-SQL stored procedures in your application to perform calculations inside the data layer, thus minimizing the number of round trips between the application and the data store.
· Your application should use spatial data, various types of data and data access patterns with joins, aggregations and complex predicates.
· Your application provides visualization and BI data models using utilities.
In the tables below, the comparison factors of both services are grouped.
This section compares the main features provided by Windows Azure Table Storage and SQL Database.
· When creating a table, you do not have any columns and the table itself is not structured and does not have a schema. Column names are parts of records stored in a table, and may be different for different records within a single table. A table may even consist of two entities with the same property name, but different types, but property names must be unique within the same record.
· Windows Azure Table Storage does not support relationality — aggregations and aggregations in queries and transactions. Entities with one key partitions are served together in one repository, and you can efficiently operate on this data, as well as modify them within the same request using Entity Group Transactions .
· There are some limitations to consider when using entity group transaction, for example, the maximum packet size is 4 MB and the fact that all entities in the packet must have one partition key.
· Windows Azure Table Storage provides one clustered index, and results are always sorted by PartitionKey and RowKey values , in ascending order. The PartitionKey and RowKey values uniquely identify each record in the table, and if you try to create two records with the same values for these properties, an exception will be thrown.
· Bandwidth criterion — a complex equation with many variables including query types and complexity, data access patterns, size of the result set, distance to the storage infrastructure, and network delays, so good advice is to constantly test performance and evaluate various factors given features of specific applications. Learn more about best practices for tables: post .
· The table below summarizes the table-supported data types for properties. Supported data types for SQL Database: Data Types (Windows Azure SQL Database) .
· You can restrict access to the SQL Database instance at the network level using the built-in firewall by configuring its rules in the management portal. Any client who can connect via HTTP / HTTPS to the Windows Azure storage can connect to the tables.
· Windows Azure Table Storage provides warranties for all insert, update, and delete transactions for one record and for Entity Group Transaction. Snapshot isolation is provided for each request. The query controls the presentation of the partition from the beginning of the query and during the execution of the transaction. For consistency between several tables, application developers are responsible.
· Windows Azure Tables supports logging, allowing you to see all queries performed. Logging also provides aggregated metrics for queries.
· Windows Azure SQL Database currently does not provide logging and metrics, but has a set of dynamic management views (DMV), useful for diagnosing problems with query performance, monitoring database connections, viewing active transactions and studying query execution plans.
· Since the Windows Azure SQL Database is based on the SQL Server engine, some concepts take place, for example, TempDB and transaction logs. To prevent uncontrolled growth of the transaction log, SQL Database imposes a limit of 10 GB per log size. The SQL Database infrastructure manages these logs to which there is no direct access. In Windows Azure Table Storage, there is no equivalent to these logs, instead, there are logging and metrics that, however, track requests, but not changeable data.
· To prevent excessive use of resources in a multi-tenant environment, both services use the throttling mechanism, which, however, differs in how these services work. For example, SQL Database uses two throttling strategies: soft throttling and hard throttling , which you can read about here .
· Windows Azure Table Storage uses a continuation token in the response header to indicate that there are more than 1000 entries in the dataset. This token can be used to retrieve the remaining data. For each request there is a snapshot consistency, whereas for requests with continuation tokens it is not.
· The total size of all properties in a table cannot exceed 1 MB, and this limit includes the size of property names and their values, which also include the required properties PartitionKey and RowKey.
· The SQL Database currently supports databases ranging in size from 5 GB (in the Web edition) to 150 GB (in the Business edition). The developer must control the size of the data so that it remains within these limits, since the configured database size does not increase as the data volume increases.
· The number of columns in a simple SQL Database table is limited to 1024 (similar to a local SQL Server), with sparse columns the same table can contain up to 30,000 columns, 1023 of which may not be sparse, 28976 should be sparse.
· Although the SQL Database can be emulated by a local installation of SQL Server, this approach does not allow to simulate a situation specific to a cloud service, for example, throttling and other restrictions.
· Windows Azure SQL Database provides an interactive query execution environment. You can also access SQL Database from console utilities, such as SSMS or third-party utilities that support ODBC.
· The T-SQL capabilities of SQL Server and SQL Database are different - some functions are limited or not supported at all, some of them have significant differences (such as database creation and Federations).
· The role-based access model supported by SQL Database provides a full range of options for configuring various modes: read-only, write-only, read-write.
· Since none of the services currently supports federated authentication based on certificates or Active Directory, you must make sure that the credentials are sufficiently secure, for example, encrypted.
· Windows Azure Table provides the ability to sign URLs using the Table SAS (Shared Access Signature). SAS allows you to issue access for a while without issuing a secret key to your account.
· The cost of outgoing traffic is calculated based on the total amount of data that goes beyond the data center to the Internet. The amount is considered for a certain period.
· Unlike SQL Database, Windows Azure Table Storage imposes transaction costs. This payment model means that you must consider the frequency of transactions as a factor in the total cost.
The decision whether to use Windows Azure Table Storage or Windows Azure SQL Database in your case depends on many factors, which, in turn, strongly depend on the specific characteristics of your application, its architecture, type of load, data access patterns.
Windows Azure Table Storage supports the ability to store large amounts of data in scalable cloud storage, up to many terabytes and billions of records. To implement this level of scaling, Windows Azure Table Storage uses a vertical scaling model to distribute records across multiple storage nodes — the service uses the NoSQL model to support this level of scaling with strict consistency. If you need cheap storage where you can store huge amounts of non-relational or simple data, consider using Windows Azure Table Storage.
Consider using Windows Azure SQL Database as extending your local SQL Server to the cloud, while offering familiar tools, support for ACID transactions with different isolation levels and complex data processing capabilities. If your data is relational and you need to consider this in managing it, SQL Database may be the best option to use.
Please note that the solution may not be to choose a single technology - you can decide how to use both technologies in your particular scenario in the best way.
Introduction
When it comes to persistent data storage in Windows Azure, there are two options for cloud technologies: Windows Azure SQL Database and Windows Azure Table Storage.
The Windows Azure SQL Database is a relational database service that extends the core functionality of SQL Server to the cloud. With SQL Database, you can deploy relational database solutions in the cloud, and the benefits of this approach include managed infrastructure, high availability, scalability, a familiar development model, and various frameworks and data access utilities - everything looks like what we see with traditional SQL Server environment. The SQL Database also offers real-time migration, export, and synchronization capabilities of local SQL Server databases with databases in Windows Azure SQL (using SQL Data Sync ).
Windows Azure Table Storage is a fault-tolerant, ISO 27001 certified NoSQL storage service (key-value) that can be useful for applications that store large amounts of non-relational data for which additional structures are needed. This service provides key-based access to data that does not have a schema. Moreover, if you store structured data without a schema, you cannot create relationships between the data.
')
Despite the tangible differences, both services are highly available managed services, for which 99.9% monthly SLA is provided.
Table Storage vs. SQL Database
Like SQL Database, Windows Azure Table Storage stores structured data. The main difference between the two services is that the SQL Database is a relational database management system based on the SQL Server engine and is built on standard principles and relational basics, thus providing features such as Transact-SQL queries, ACID transactions, stored procedures performed on the server side.
Windows Azure Table Storage is a flexible key-value entity storage that allows you to quickly create a cloud-based application without locking the application's data model to a specific set of schemas. This service is not a relational data repository and does not provide such capabilities for managing relational data as SQL Database (for example, join-s and stored procedures). Windows Azure Table Storage has limited support for server-side queries, but has transaction functions. In addition, different records within the same table can have a different structure, and this approach in Windows Azure Table Storage allows you to efficiently store and operate with simple relational data.
If your application stores and operates with large amounts of data for which there is no need to use relational functions, Windows Azure Table Storage may be a more appropriate option. If your application needs to handle datasets combined with any schema, SQL Database looks like a better option than Windows Azure Table Storage. There are several other factors to consider before deciding whether to use SQL Database or Windows Azure Table Storage, some of which are listed below.
Considerations for choosing technology
When determining a data storage technology that is appropriate for a particular solution, the architect and the developer should consider the following recommendations:
Consider using Windows Azure Table Storage when:
· Your application should store large amounts of data (for example, many terabytes) in low-cost storage.
· Your application stores and operates with large data arrays that do not have complex relational relations, for which you need to use server-side join-s, secondary indexes, or some kind of complex logic running on the server side.
· Your application needs a flexible data scheme for storing objects that are heterogeneous in their scheme, the structure of which is difficult to determine at the design stage.
· Your business needs data storage capabilities in case of catastrophic situations using geographic spacing. Windows Azure tables are geographically replicated across two datacenters located a few hundred miles from each other, but on the same continent, which provides additional confidence in data integrity in the event of a disaster.
· You need to store more than 150 GB of data without using sharding or partitioning.
· You need a high level of scaling without manual sharding data.
Consider using Windows Azure SQL Database when:
· Your application performs data processing that has a high degree of structuredness with relationships and schemas.
· Your data is essentially relational and needs to implement the key principles of the software model of relational data to ensure data integrity through data uniqueness rules, constraints, and various types of keys.
· The amount of your data may not exceed 150 Gb per dedicated storage unit (database), however you can partition your data into several databases if this limit is exceeded, which may be changed in the future.
· Your existing data-oriented applications are already using SQL Server, but you need access to cloud storage using existing frameworks and the ability to transparently migrate between the local infrastructure and Windows Azure.
· You plan to use T-SQL stored procedures in your application to perform calculations inside the data layer, thus minimizing the number of round trips between the application and the data store.
· Your application should use spatial data, various types of data and data access patterns with joins, aggregations and complex predicates.
· Your application provides visualization and BI data models using utilities.
 Note |
| Many applications in Windows Azure can take advantage of both technologies, however it is recommended to use them in conjunction. |
Comparing Windows Azure Table Storage and SQL Database
In the tables below, the comparison factors of both services are grouped.
Main features
This section compares the main features provided by Windows Azure Table Storage and SQL Database.
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Relationship between data | Not Windows Azure Table Storage does not provide methods for creating relationships between data. Instead, you can implement simple links using the non-schematic properties of the tables and structuring the data in a specific format. | Yes Similar to SQL Server, SQL Database allows you to define relationships between data stored in different tables using foreign keys. |
| Server side processing | Not The following operations are supported: insert , update , delete , select ; not supported: unions, foreign keys, stored procedures, triggers, server-side processing. | Yes The standard set of SQL Server functions is stored procedures, views, complex indexes, joins, aggregations. |
| Transaction support | Limited Transactions within one table and one partition are supported, in a transaction - up to 100 operations, while optimistic parallelism is supported. | Yes Traditional ACID transactions are supported within one database, between databases they are not supported. Optimistic concurrency is supported. |
| Geographical Replication | Yes By default, the table is replicated to other data centers within the region. | Not Currently, the SQL Database is not replicated to other data centers within the region. |
| Scheme in the table | Relaxed Each entry can have its own set of properties. | Driven by The scheme is defined, but can be changed at any time, all entries must follow this scheme. Consider using XML type or sparse columns for additional flexibility. |
| Is it comparable to existing local data stores? | Not There are no local alternatives to cloud storage. | Yes Analog SQL Server with certain restrictions - General Guidelines and Limitations . |
| Vertical scaling | Automatic Partitioned based on the PartitionKey property. The table can be stored in different partitions on different devices, which allows clients to perform parallel access. | Manual Sharding between a database group using SQL Federations or your own approach to sharding. |
| Data types | Simple See table in “Additional Information”. | Simple, complex, user-defined SQL Database supports a large set of data types, including the ability to define a type by the user. |
Additional Information
· When creating a table, you do not have any columns and the table itself is not structured and does not have a schema. Column names are parts of records stored in a table, and may be different for different records within a single table. A table may even consist of two entities with the same property name, but different types, but property names must be unique within the same record.
· Windows Azure Table Storage does not support relationality — aggregations and aggregations in queries and transactions. Entities with one key partitions are served together in one repository, and you can efficiently operate on this data, as well as modify them within the same request using Entity Group Transactions .
· There are some limitations to consider when using entity group transaction, for example, the maximum packet size is 4 MB and the fact that all entities in the packet must have one partition key.
· Windows Azure Table Storage provides one clustered index, and results are always sorted by PartitionKey and RowKey values , in ascending order. The PartitionKey and RowKey values uniquely identify each record in the table, and if you try to create two records with the same values for these properties, an exception will be thrown.
· Bandwidth criterion — a complex equation with many variables including query types and complexity, data access patterns, size of the result set, distance to the storage infrastructure, and network delays, so good advice is to constantly test performance and evaluate various factors given features of specific applications. Learn more about best practices for tables: post .
· The table below summarizes the table-supported data types for properties. Supported data types for SQL Database: Data Types (Windows Azure SQL Database) .
| Type of | Details |
| Binary | Array of bytes up to 64 KB. |
| Bool | Boolean. |
| Datetime | 64-bit value of UTC time. The range of values is from 1/1/1601 to 12/31/9999. |
| Double | 64-bit floating point value. |
| GUID | 128 bit GUID. |
| Int | 32-bit integer. |
| Int64 | 64-bit integer. |
| String | The value in UTF-16 is up to 64 Kb. |
Advanced features
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Available from local applications or other platforms (except Windows Azure) | Yes | Yes |
| Consistency model | Strict | Strict |
| Support for Windows Communication Foundation (WCF) Data Services | Yes | Yes |
| REST support | Yes Support by default. | Yes Support for REST-based access by adding an OData layer on top of the database. |
| Firewall Protection (IP Restriction) | Not | Yes Windows Azure firewall, configured from the portal or via the console, is used. |
| Transaction throttling behavior | Yes Read more - blog post . | Yes Read more - article . |
| Error tolerance | Yes To ensure a high level of fault tolerance, the stored data is replicated into three copies within the region and another three copies to another data center in the same region. | Yes The data center stores three copies of each instance of SQL Database. |
| Logging and metrics | Yes Read more - blog post . | Not |
| Transaction logs | Not | Yes The size of the transaction log is limited to 10 GB with a limit of 1 GB per transaction. |
Additional Information
· You can restrict access to the SQL Database instance at the network level using the built-in firewall by configuring its rules in the management portal. Any client who can connect via HTTP / HTTPS to the Windows Azure storage can connect to the tables.
· Windows Azure Table Storage provides warranties for all insert, update, and delete transactions for one record and for Entity Group Transaction. Snapshot isolation is provided for each request. The query controls the presentation of the partition from the beginning of the query and during the execution of the transaction. For consistency between several tables, application developers are responsible.
· Windows Azure Tables supports logging, allowing you to see all queries performed. Logging also provides aggregated metrics for queries.
· Windows Azure SQL Database currently does not provide logging and metrics, but has a set of dynamic management views (DMV), useful for diagnosing problems with query performance, monitoring database connections, viewing active transactions and studying query execution plans.
· Since the Windows Azure SQL Database is based on the SQL Server engine, some concepts take place, for example, TempDB and transaction logs. To prevent uncontrolled growth of the transaction log, SQL Database imposes a limit of 10 GB per log size. The SQL Database infrastructure manages these logs to which there is no direct access. In Windows Azure Table Storage, there is no equivalent to these logs, instead, there are logging and metrics that, however, track requests, but not changeable data.
· To prevent excessive use of resources in a multi-tenant environment, both services use the throttling mechanism, which, however, differs in how these services work. For example, SQL Database uses two throttling strategies: soft throttling and hard throttling , which you can read about here .
Capacity and quotas
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Maximum record size | 1 Mb No more than 255 properties in which three required are included: PartitionKey , RowKey , Timestamp . | 2 GB Up to 1024 columns (30,000 if sparse columns are used). Using varchar (max) , varbinary (max) , xml , text , and image allows an additional 2 GB to be used. |
| Maximum data size | 100 TB per table One storage account (with tables, blobs and queues) can be up to 100 TB in size, the maximum size of the table is 100 TB. | 150 GB on a DB Despite the possibility of increasing the upper limit of the size of the database in the future, pay attention to SQL Federations. |
| Maximum number of records returned in one request | 1,000 No more than 1000 entries in one request. If the result is greater than this amount, the continuation token is returned. | Not limited If configured incorrectly, there may be a problem with limiting the number due to request and connection timeouts. |
Additional Information
· Windows Azure Table Storage uses a continuation token in the response header to indicate that there are more than 1000 entries in the dataset. This token can be used to retrieve the remaining data. For each request there is a snapshot consistency, whereas for requests with continuation tokens it is not.
· The total size of all properties in a table cannot exceed 1 MB, and this limit includes the size of property names and their values, which also include the required properties PartitionKey and RowKey.
· The SQL Database currently supports databases ranging in size from 5 GB (in the Web edition) to 150 GB (in the Business edition). The developer must control the size of the data so that it remains within these limits, since the configured database size does not increase as the data volume increases.
· The number of columns in a simple SQL Database table is limited to 1024 (similar to a local SQL Server), with sparse columns the same table can contain up to 30,000 columns, 1023 of which may not be sparse, 28976 should be sparse.
Control
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Control Protocol and Utilities | REST over HTTP / HTTPS You can use Windows Azure Storage Explorer or a third-party utility like Cloud Storage Studio. | ODBC / JDBC REST over HTTP / HTTPS You can use the management portal or SQL Server Management Studio. |
| Data access | Odata You can access data using the HTTP (S) REST API or the .NET Client Library for WCF Data Services, included with the Windows Azure SDK. | ODBC / JDBC You can use applications written using traditional data access technologies, such as ADO.NET and ODBC, which can communicate with SQL Server to access an instance of SQL Database with minimal code changes. |
| Java API support | Yes | Yes |
| Support Node.js API | Yes | Yes |
| Support PHP API | Yes | Yes |
| Support LINQ | Yes | Yes |
| Support Python | Yes | Not |
| Offline development | Yes Availability of a local storage emulator from the Windows Azure SDK. | Not SQL Express and other editions of SQL Server are other products that do not provide full emulation of the Windows Azure SQL Database cloud environment. |
Additional Information
· Although the SQL Database can be emulated by a local installation of SQL Server, this approach does not allow to simulate a situation specific to a cloud service, for example, throttling and other restrictions.
· Windows Azure SQL Database provides an interactive query execution environment. You can also access SQL Database from console utilities, such as SSMS or third-party utilities that support ODBC.
· The T-SQL capabilities of SQL Server and SQL Database are different - some functions are limited or not supported at all, some of them have significant differences (such as database creation and Federations).
Authentication and Authorization
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Authentication | Symmetric key Shared Access Signatures For user authentication, a 512-bit HMAC key is used. | SQL authentication For user authentication, standard SQL authentication is used. |
| Role-based access | Not | Yes Standard database roles and SQL applications are supported. |
| Windows Azure Active Directory (formerly ACS) | Not | Not |
| Federation with Identity Provider | Not | Not |
Additional Information
· The role-based access model supported by SQL Database provides a full range of options for configuring various modes: read-only, write-only, read-write.
· Since none of the services currently supports federated authentication based on certificates or Active Directory, you must make sure that the credentials are sufficiently secure, for example, encrypted.
· Windows Azure Table provides the ability to sign URLs using the Table SAS (Shared Access Signature). SAS allows you to issue access for a while without issuing a secret key to your account.
Cost of
| Comparison criterion | Windows Azure Table Storage | SQL Database |
| Cost of storage | $ 0.125 per gigabyte per month, calculated on the basis of daily load. | Calculated based on the size of the database. |
| Transaction cost | $ 0.01 for 100,000 transactions. | $ 0.00 In SQL Database transactions are not paid. |
| Paid operations | Everything The cost of storage is added to the cost of transactions. | None The cost does not depend on the number of transactions, only on the size of the database. |
| Cost of outgoing traffic | $ 0.12 - $ 0.19 per gigabyte depends on the region | $ 0.12 - $ 0.19 per gigabyte depends on the region |
Additional Information
· The cost of outgoing traffic is calculated based on the total amount of data that goes beyond the data center to the Internet. The amount is considered for a certain period.
· Unlike SQL Database, Windows Azure Table Storage imposes transaction costs. This payment model means that you must consider the frequency of transactions as a factor in the total cost.
Conclusion
The decision whether to use Windows Azure Table Storage or Windows Azure SQL Database in your case depends on many factors, which, in turn, strongly depend on the specific characteristics of your application, its architecture, type of load, data access patterns.
Windows Azure Table Storage supports the ability to store large amounts of data in scalable cloud storage, up to many terabytes and billions of records. To implement this level of scaling, Windows Azure Table Storage uses a vertical scaling model to distribute records across multiple storage nodes — the service uses the NoSQL model to support this level of scaling with strict consistency. If you need cheap storage where you can store huge amounts of non-relational or simple data, consider using Windows Azure Table Storage.
Consider using Windows Azure SQL Database as extending your local SQL Server to the cloud, while offering familiar tools, support for ACID transactions with different isolation levels and complex data processing capabilities. If your data is relational and you need to consider this in managing it, SQL Database may be the best option to use.
Please note that the solution may not be to choose a single technology - you can decide how to use both technologies in your particular scenario in the best way.
Source: https://habr.com/ru/post/151394/
All Articles