What is your primary use case for Couchbase?

I have used Couchbase Enterprise in a different way. I used it in Informatica to set up an end-to-end flow for the connector. Informatica used to connect to Couchbase for all three applications: IICS Cloud and Informatica. Couchbase is running on a Linux server, then I connected using Informatica connectors and evaluated how the connector works with different bucket sizes. I focused on low latency using high-performance NoSQL stores, data validation, integrating Couchbase with PySpark and Great Expectations. I performed end-to-end API and database testing, including event-driven testing. Mostly, I used it for distributed system testing. I integrated a workflow as a core data store within a data pipeline for QA validation. Couchbase Enterprise acts as my primary NoSQL database for storing JSON documents such as orders and users. The API interacts directly with Couchbase Enterprise for low latency read and write operations. I validate API responses versus database data consistency and data correctness after business operations. For data pipeline validation, I use PySpark to extract data from Couchbase Enterprise for large-scale validation, which is useful in ETL data engineering workflows. I then use data quality automation with Great Expectations where I perform data quality checks such as schema, null, range, and business rules validation. For end-to-end testing, I verify whether all data and subsequent data landed into the target correctly from source to database. I also tested distributed system scenarios including failover, recovery, rebalancing, replication, and load balancing to ensure the cluster responds correctly without any data loss when a node goes down. I then evaluated query performance across these scenarios.

Couchbase Enterprise serves as our primary solution for persisting data into the database, and as a document-based data structure, it is one of the efficient solutions for our architecture. For example, I had one of the microservices, Product Inventory Sync, and for that, we used particular documents which were first persisted into Couchbase Enterprise; these were Product Inventory Loader documents, and based on ID, it was very easy for me to search and find particular records in our database once they were persisted. Another scenario related to customer service is the billing account service, where in multiple domains and subdomains we use Couchbase Enterprise, and we chose it for its inbuilt cache, which helped us significantly with performance; additionally, we were able to write queries on top of that and retrieve our data based on customer ID, billing account ID, and various other parameters, allowing easy data searches from Couchbase NoSQL database.

Our main use case for Couchbase Enterprise involves feature configuration management in the hospitality domain. Ours is a SaaS product, and we expose our product to multiple customers such as Marriott, IHG, and MGM, which are chains of hotels. We differentiate the features based on their subscription plans, such as one billion subscription plan from GMG versus a 500 million subscription plan from IHG. In this way, we use FCAM to identify and configure the features that specific chains are entitled to use, storing these configurations in separate documents in Couchbase for IHG, MGM, and Marriott. We use Couchbase Enterprise to store NoSQL data. We have a new feature called feature configuration management where we store each document in Couchbase for each chain, maintaining separate repository configurations for each. Mostly we use Couchbase Enterprise for this use case only.

Couchbase Enterprise is a powerful NoSQL database solution designed for scalability and high performance. I have used Couchbase Enterprise specifically for the performance and querying aspects, where I utilized the N1QL query language, which is the official language for Couchbase. This is a significant advantage because it makes querying documents intuitive for developers who already know SQL. My main use case includes using the built-in cache of Couchbase Enterprise. The built-in cache layer reduces the need for external caching solutions like Redis, which simplifies architecture. Additionally, it has cross-data center replication so that replication across data centers is smooth and adds resilience if anything goes down. It also integrates well with the ecosystem, including modern frameworks and supports SDKs for multiple languages such as Java. I used the flexible data model in a real-time billing project where there are situations requiring nested data storage. The nesting can be as deep as five layers, and it is easy to fetch data in the nested layers using Couchbase Enterprise. Couchbase Enterprise is deployed on-premises in my organization. I used this in Amdocs company, which operates in the telecommunication domain. Couchbase Enterprise is high-performance for real-time workloads and has built-in caching, which reduces the need for external systems. It has cross-data center replication which makes global replication straightforward, and it includes the N1QL query language which is very familiar with SQL-like syntax for querying.

Basically we have clusters, Couchbase clusters, databases, and that is how we use Couchbase with XDCR. All the clusters are set up and then we use Couchbase. It is a complex application setup we use with Couchbase. We have replication and multi-node Couchbase setup.

I have two use cases right now. I have a shopping list app where users can share their lists, so I used the Sync feature with Sync Gateway.In another product, I use what they call N1QL, which is a query language, and I use it to check if ads are available to show to a user. In one part of the product, I only use the Sync Gateway, and in another part, I use N1QL to query the database.

We used Couchbase ( /products/couchbase-reviews ) as the primary data storage. Since our company was in the gaming industry, Couchbase ( /products/couchbase-reviews ) stored data on players and related to games, levels, and similar objects for our mobile applications, aka games. There was a synchronization in place between Couchbase and another database, Elasticsearch. Some indices from Couchbase were periodically replicated to Elasticsearch.

Our primary use case for Couchbase is related to the iGaming industry, particularly for high-performance reads and writes to meet our SLA for high volumes. We have a particular use case where there is an SLA of one second, and Couchbase is critical for ensuring our wallet operations function correctly.

In my company, we use the enterprise version of Couchbase, and it is used across the organization for its database operations. We do only use the NoSQL database, not Couchbase Capella. The tool is mostly for document-based storage of Cisco, which is a retail company. We manage a lot of product information and send a lot of metadata that we generate for all of our orders, including baskets and other aspects. We use Couchbase heavily for document-based storage purposes.

Initially we were using the on-premise Couchbase Server which was maintained by the organisation with assistance from a consultant from Couchbase. After they came up with the cloud version of Couchbase called Capella, it was decided to migrate there to reduce the maintenance cost and to take advantage of the advanced features the product offers. Couchbase Capella offered distinct advantages like ease of horizontal and vertical autoscaling, ease of querying using the SQL++ language (which is not hard to learn), and the flexibility it offers while being hosted in the cloud and being served by the parent company.

We manage our telecommunication application using the product.

We're in the middle of building out a persistent cache layer using Couchbase. That's across multiple international regions, but we have other instances where we're using it for data stores and some for its analytics features.

I was working on a game called Infinite Fleet and the backend for that particular game was written in Golang and our database of choice was Couchbase. We were dealing with a lot of unstructured data and were leveraging the load balancing capabilities of Couchbase. The data that is stored on our Couchbase instances includes player profiles and metrics. We have a total of 25 developers who use it.

In the beginning, we used this solution to store configuration data. We had a system that we used for management for our platforms. We then needed a system that could help with configuration of platforms. We were looking at a couple of different options of how to store those configurations dynamically. We have 17 people that use this solution in total. It took us a while to figure out how to use this solution.

We're using Couchbase for general purposes and for caching.

In our current project, we use this solution in the healthcare field for the telemedical industry and in other projects in the automation industry.

We are solution providers and we are vendors. We provide products to our clients. I am working on Couchbase and Elasticsearch together. We use Couchbase as a family data engine for immigration assistance. We use Elasticsearch to replicate the data in realtime from Couchbase, and then we use the search functionality via Elasticsearch. We are building a property listing system and when it was created we stored all of the data in Couchbase in realtime. We scrape from different sources and select the data from the user agents, and the property agent as well, and then store it. There is a retrieval method built into Couchbase.

There are many shifts and we use Couchbase to log that data whenever they travel from one place to another. We log the data and we merge it in the backend. That's how the application and everything works. If you are a temp person on one shift and you have logged data, we use the nearby API to connect them and to pull and push each other's data. We also use Couchbase for Android tablet to the cloud.

We use it for data link utilization.