Couchbase vs Azure SQL Database

• Couchbase performance is exceptional both for in-memory and persisted transactions.
• Handling of node failures and cluster rebalancing (high availability).
• Enterprise support from Couchbase themselves
• Good documentation
• Streaming of bucket (database) level mutations via their Database Change Protocol (DCP).
• Replication of datasets between native clients and Couchbase buckets
• Handling of simultaneous writes to the same record with performance penalties

Read full review

• Maintenance is always an issue, so using a cloud solution saves a lot of trouble.
• On premise solutions always suffer from fragmented implementations here and there, where several "dba's" keep track of security and maintenance. With a cloud database it's much easier to keep a central overview.
• Security options in SQL database are next level... data masking, hiding sensitive data where always neglected on premise, whereas you'll get this automatically in the cloud.

Read full review

• The N1QL engine performs poorly compared to SQL engines due to the number of interactions needed, so if your use case involves the need for a lot of SQL-like query activity as opposed to the direct fetch of data in the form of a key/value map you may want to consider a RDBMS that has support for json data types so that you can more easily mix the use of relational and non-relational approaches to data access.
• You have to be careful when using multiple capabilities (e.g. transactions with Sync Gateway) as you will typically run into problems where one technology may not operate correctly in combination with another.
• There are quality problems with some newly released features, so be careful with being an early adopter unless you really need the capability. We somewhat desperately adopted the use of transactions, but went through multiple bughunt cycles with Couchbase working the kinks out.

Read full review

• One needs to be aware that some T-SQL features are simply not available.
• The programmatic access to server, trace flags, hardware from within Azure SQL Database is taken away (for a good reason).
• No SQL Agent so your jobs need to be orchestrated differently.
• The maximum concurrent logins maybe an unexpected problem.
• Sudden disconnects.
• The developers and admin must study the capacity and tier usage limits https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits otherwise some errors or even transaction aborts never seen before can occur.
• Only one Latin Collation choice.
• There is no way to debug T-SQL ( a big drawback in my point of view).

Read full review

• Great performance.
• Leading Couchbase Lite capabilities for mobile use.
• Developers' learning curve with replica reads and multi cluster can be long. Needs guidance and nurturing.
• Cluster maintenance during OS patching, etc. has multiple ways to approach. Operational teams may need some guidance.

Read full review

• Perfect for small and medium databases, being very cost effective.
• As a Platform as a Service, there is no concern about patches, upgrades and end of life.
• Be aware of security and network capabilities. The service cannot run in the VNET as Azure Virtual Machines do.

Read full review