In our application we have been using Couchbase without scopes and collections (everything under a bucket). Due to new customer requirements, we are now planning to implement scopes and collections in our code.
Before we move ahead and prepare for the required development efforts, I would like to get expert opinions on the following points:
What are the potential adverse impacts (if any) of using scopes and collections in both N1QL queries and KV operations?
Is there any impact on index creation and size when using collections vs. traditional bucket-level indexes?
Does Couchbase fully support joins between scoped and non-scoped documents (e.g., collection-to-default collection), and are there any performance implications?
What are the best practices for migrating existing codes into scopes and collections with minimal risk?
Does introducing multiple scopes/collections add extra operational overhead (RBAC, backup/restore, rebalance)?
Are all Couchbase services and SDKs (Backup, XDCR) fully compatible with scopes and collections?
Are there recommended scaling limits on the number of scopes/collections per bucket/cluster for performance reasons?
From a future-proofing perspective, are there features in newer Couchbase versions that will only work with scopes/collections?
There is no difference using scopes and collections. That is all. No difference. The documentation is here Scopes and Collections | Couchbase Docs Scopes and Collections | Couchbase Docs
Thanks @vsr1 for your reply. Could you please help me on above points whether these kind of join possible or not. Secondly is there any adverse impact on Index creations.
The joins are possible. If you have doubts about the accuracy of the documentation, you can execute the joins in Query Tab of the web ui!! Likewise with what you want yo know about indexes.
As @vsr1 has said - everyone has been using scopes and collections since 7.0 was released in July 2021whether they knew it or not - using a bucket without a scope or collection results in the collection named _default in the scope named _default being used.
Is there a compelling reason to use scope and collection beyond the points mentioned in the link below?
If we do not identify major benefits beyond the mentioned points, migrating legacy code will require significant effort. From a future-proofing perspective, do newer Couchbase versions offer features that only work with scopes and collections?
In 7,x bucket with out explicit scope/collection means bucket, _default scope, _default collection
All futures work on collections and as bucket is specialized collection it will work there to. As of now legacy code still work, change legacy code or not is your business decision.
If you are having trouble with deciding how to develop and maintain your software, you can engage Couchbase Professional Services or a third-party consultant. The documentation can only provide general information, it’s up to you to decide what you want to do with that information.