Alternatives to CouchDB logo

Alternatives to CouchDB

MongoDB, Couchbase, Cloudant, MariaDB, and RethinkDB are the most popular alternatives and competitors to CouchDB.
501
577
+ 1
139

What is CouchDB and what are its top alternatives?

Apache CouchDB is a database that uses JSON for documents, JavaScript for MapReduce indexes, and regular HTTP for its API. CouchDB is a database that completely embraces the web. Store your data with JSON documents. Access your documents and query your indexes with your web browser, via HTTP. Index, combine, and transform your documents with JavaScript.
CouchDB is a tool in the Databases category of a tech stack.
CouchDB is an open source tool with 6.1K GitHub stars and 1K GitHub forks. Here’s a link to CouchDB's open source repository on GitHub

Top Alternatives to CouchDB

  • MongoDB
    MongoDB

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...

  • Couchbase
    Couchbase

    Developed as an alternative to traditionally inflexible SQL databases, the Couchbase NoSQL database is built on an open source foundation and architected to help developers solve real-world problems and meet high scalability demands. ...

  • Cloudant
    Cloudant

    Cloudant’s distributed database as a service (DBaaS) allows developers of fast-growing web and mobile apps to focus on building and improving their products, instead of worrying about scaling and managing databases on their own. ...

  • MariaDB
    MariaDB

    Started by core members of the original MySQL team, MariaDB actively works with outside developers to deliver the most featureful, stable, and sanely licensed open SQL server in the industry. MariaDB is designed as a drop-in replacement of MySQL(R) with more features, new storage engines, fewer bugs, and better performance. ...

  • RethinkDB
    RethinkDB

    RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn. ...

  • Redis
    Redis

    Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. ...

  • Riak
    Riak

    Riak is a distributed database designed to deliver maximum data availability by distributing data across multiple servers. As long as your client can reach one Riak server, it should be able to write data. In most failure scenarios, the data you want to read should be available, although it may not be the most up-to-date version of that data. ...

  • Cassandra
    Cassandra

    Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. ...

CouchDB alternatives & related posts

MongoDB logo

MongoDB

92.1K
79.5K
4.1K
The database for giant ideas
92.1K
79.5K
+ 1
4.1K
PROS OF MONGODB
  • 827
    Document-oriented storage
  • 593
    No sql
  • 553
    Ease of use
  • 464
    Fast
  • 410
    High performance
  • 257
    Free
  • 218
    Open source
  • 180
    Flexible
  • 145
    Replication & high availability
  • 112
    Easy to maintain
  • 42
    Querying
  • 39
    Easy scalability
  • 38
    Auto-sharding
  • 37
    High availability
  • 31
    Map/reduce
  • 27
    Document database
  • 25
    Easy setup
  • 25
    Full index support
  • 16
    Reliable
  • 15
    Fast in-place updates
  • 14
    Agile programming, flexible, fast
  • 12
    No database migrations
  • 8
    Easy integration with Node.Js
  • 8
    Enterprise
  • 6
    Enterprise Support
  • 5
    Great NoSQL DB
  • 4
    Support for many languages through different drivers
  • 3
    Schemaless
  • 3
    Aggregation Framework
  • 3
    Drivers support is good
  • 2
    Fast
  • 2
    Managed service
  • 2
    Easy to Scale
  • 2
    Awesome
  • 2
    Consistent
  • 1
    Good GUI
  • 1
    Acid Compliant
CONS OF MONGODB
  • 6
    Very slowly for connected models that require joins
  • 3
    Not acid compliant
  • 1
    Proprietary query language

related MongoDB posts

Shared insights
on
Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

  1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

  2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

  3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

See more
Vaibhav Taunk
Team Lead at Technovert · | 31 upvotes · 4M views

I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.

See more
Couchbase logo

Couchbase

474
601
110
Document-Oriented NoSQL Database
474
601
+ 1
110
PROS OF COUCHBASE
  • 18
    High performance
  • 18
    Flexible data model, easy scalability, extremely fast
  • 9
    Mobile app support
  • 7
    You can query it with Ansi-92 SQL
  • 6
    All nodes can be read/write
  • 5
    Equal nodes in cluster, allowing fast, flexible changes
  • 5
    Both a key-value store and document (JSON) db
  • 5
    Open source, community and enterprise editions
  • 4
    Automatic configuration of sharding
  • 4
    Local cache capability
  • 3
    Easy setup
  • 3
    Linearly scalable, useful to large number of tps
  • 3
    Easy cluster administration
  • 3
    Cross data center replication
  • 3
    SDKs in popular programming languages
  • 3
    Elasticsearch connector
  • 3
    Web based management, query and monitoring panel
  • 2
    Map reduce views
  • 2
    DBaaS available
  • 2
    NoSQL
  • 1
    Buckets, Scopes, Collections & Documents
  • 1
    FTS + SQL together
CONS OF COUCHBASE
  • 3
    Terrible query language

related Couchbase posts

Gabriel Pa

We implemented our first large scale EPR application from naologic.com using CouchDB .

Very fast, replication works great, doesn't consume much RAM, queries are blazing fast but we found a problem: the queries were very hard to write, it took a long time to figure out the API, we had to go and write our own @nodejs library to make it work properly.

It lost most of its support. Since then, we migrated to Couchbase and the learning curve was steep but all worth it. Memcached indexing out of the box, full text search works great.

See more
Ilias Mentzelos
Software Engineer at Plum Fintech · | 9 upvotes · 233.6K views
Shared insights
on
MongoDBMongoDBCouchbaseCouchbase

Hey, we want to build a referral campaign mechanism that will probably contain millions of records within the next few years. We want fast read access based on IDs or some indexes, and isolation is crucial as some listeners will try to update the same document at the same time. What's your suggestion between Couchbase and MongoDB? Thanks!

See more
Cloudant logo

Cloudant

84
73
28
Distributed database-as-a-service (DBaaS) for web & mobile apps
84
73
+ 1
28
PROS OF CLOUDANT
  • 13
    JSON
  • 7
    REST interface
  • 4
    Cheap
  • 3
    JavaScript support
  • 1
    Great syncing
CONS OF CLOUDANT
    Be the first to leave a con

    related Cloudant posts

    Josh Dzielak
    Co-Founder & CTO at Orbit · | 5 upvotes · 151K views

    As a side project, I was building a note taking app that needed to synchronize between the client and the server so that it would work offline. At first I used Firebase to store the data on the server and wrote my own code to cache Firebase data in local storage and synchronize it. This was brittle and not performant. I figured that someone else must have solved this in a better way so I went looking for a better solution.

    I needed a tool where I could write the data once and it would write to client and server, and when clients came back on line they would automatically catch the client up. I also needed conflict resolution. I was thrilled to discover Pouchdb and its server-side counterpart CouchDB. Together, they met nearly all of my requirements and were very easy to implement - I was able to remove a ton of custom code and have found the synchronization to be very robust. Pouchdb 7 has improved mobile support too, so I can run the app on iOS or Android browsers.

    My Couchdb instance is actually a Cloudant instance running on IBM Bluemix. For my fairly low level of API usage, it's been totally free, and it has a decent GUI for managing users and replications.

    See more
    MariaDB logo

    MariaDB

    16.1K
    12.5K
    468
    An enhanced, drop-in replacement for MySQL
    16.1K
    12.5K
    + 1
    468
    PROS OF MARIADB
    • 149
      Drop-in mysql replacement
    • 100
      Great performance
    • 74
      Open source
    • 55
      Free
    • 44
      Easy setup
    • 15
      Easy and fast
    • 14
      Lead developer is "monty" widenius the founder of mysql
    • 6
      Also an aws rds service
    • 4
      Consistent and robust
    • 4
      Learning curve easy
    • 2
      Native JSON Support / Dynamic Columns
    • 1
      Real Multi Threaded queries on a table/db
    CONS OF MARIADB
      Be the first to leave a con

      related MariaDB posts

      Tassanai Singprom

      This is my stack in Application & Data

      JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

      My Utilities Tools

      Google Analytics Postman Elasticsearch

      My Devops Tools

      Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

      My Business Tools

      Slack

      See more
      Joshua Dean Küpper
      CEO at Scrayos UG (haftungsbeschränkt) · | 11 upvotes · 663.1K views

      We primarily use MariaDB but use PostgreSQL as a part of GitLab , Sentry and Nextcloud , which (initially) forced us to use it anyways. While this isn't much of a decision – because we didn't have one (ha ha) – we learned to love the perks and advantages of PostgreSQL anyways. PostgreSQL's extension system makes it even more flexible than a lot of the other SQL-based DBs (that only offer stored procedures) and the additional JOIN options, the enhanced role management and the different authentication options came in really handy, when doing manual maintenance on the databases.

      See more
      RethinkDB logo

      RethinkDB

      298
      405
      307
      JSON. Scales to multiple machines with very little effort. Open source.
      298
      405
      + 1
      307
      PROS OF RETHINKDB
      • 48
        Powerful query language
      • 46
        Excellent dashboard
      • 42
        JSON
      • 41
        Distributed database
      • 38
        Open source
      • 25
        Reactive
      • 16
        Atomic updates
      • 15
        Joins
      • 9
        MVCC concurrency
      • 9
        Hadoop-style map/reduce
      • 4
        Geospatial support
      • 4
        Real-time, open-source, scalable
      • 2
        YC Company
      • 2
        A NoSQL DB with joins
      • 2
        Great Admin UI
      • 2
        Changefeeds: no polling needed to get updates
      • 2
        Fast, easily scalable, great customer support
      CONS OF RETHINKDB
        Be the first to leave a con

        related RethinkDB posts

        Łukasz Korecki
        CTO & Co-founder at EnjoyHQ · | 12 upvotes · 125.5K views

        We initially chose RethinkDB because of the schema-less document store features, and better durability resilience/story than MongoDB In the end, it didn't work out quite as we expected: there's plenty of scalability issues, it's near impossible to run analytical workloads and small community makes working with Rethink a challenge. We're in process of migrating all our workloads to PostgreSQL and hopefully, we will be able to decommission our RethinkDB deployment soon.

        See more

        Dear Team, Please advise the stack to be used for building Chat Applications that cater to billions of users and work on Mobile as well as desktop. I don't want to use Firebase since it is not fitting into my use case of not using third Party Service Provider. I am comfortable with Java/PHP as a backend. Can we consider RethinkDB, MySQL, and GunDB for the application?

        Also looking for Push methodology and not polling one for sending Realtime updates.

        Regards Sukesh

        See more
        Redis logo

        Redis

        58.6K
        45.1K
        3.9K
        Open source (BSD licensed), in-memory data structure store
        58.6K
        45.1K
        + 1
        3.9K
        PROS OF REDIS
        • 886
          Performance
        • 542
          Super fast
        • 513
          Ease of use
        • 444
          In-memory cache
        • 324
          Advanced key-value cache
        • 194
          Open source
        • 182
          Easy to deploy
        • 164
          Stable
        • 155
          Free
        • 121
          Fast
        • 42
          High-Performance
        • 40
          High Availability
        • 35
          Data Structures
        • 32
          Very Scalable
        • 24
          Replication
        • 22
          Great community
        • 22
          Pub/Sub
        • 19
          "NoSQL" key-value data store
        • 16
          Hashes
        • 13
          Sets
        • 11
          Sorted Sets
        • 10
          NoSQL
        • 10
          Lists
        • 9
          Async replication
        • 9
          BSD licensed
        • 8
          Bitmaps
        • 8
          Integrates super easy with Sidekiq for Rails background
        • 7
          Keys with a limited time-to-live
        • 7
          Open Source
        • 6
          Lua scripting
        • 6
          Strings
        • 5
          Awesomeness for Free
        • 5
          Hyperloglogs
        • 4
          Transactions
        • 4
          Outstanding performance
        • 4
          Runs server side LUA
        • 4
          LRU eviction of keys
        • 4
          Feature Rich
        • 4
          Written in ANSI C
        • 4
          Networked
        • 3
          Data structure server
        • 3
          Performance & ease of use
        • 2
          Dont save data if no subscribers are found
        • 2
          Automatic failover
        • 2
          Easy to use
        • 2
          Temporarily kept on disk
        • 2
          Scalable
        • 2
          Existing Laravel Integration
        • 2
          Channels concept
        • 2
          Object [key/value] size each 500 MB
        • 2
          Simple
        CONS OF REDIS
        • 15
          Cannot query objects directly
        • 3
          No secondary indexes for non-numeric data types
        • 1
          No WAL

        related Redis posts

        Russel Werner
        Lead Engineer at StackShare · | 32 upvotes · 2.5M views

        StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

        Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

        #StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

        See more
        Simon Reymann
        Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 9.7M views

        Our whole DevOps stack consists of the following tools:

        • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
        • Respectively Git as revision control system
        • SourceTree as Git GUI
        • Visual Studio Code as IDE
        • CircleCI for continuous integration (automatize development process)
        • Prettier / TSLint / ESLint as code linter
        • SonarQube as quality gate
        • Docker as container management (incl. Docker Compose for multi-container application management)
        • VirtualBox for operating system simulation tests
        • Kubernetes as cluster management for docker containers
        • Heroku for deploying in test environments
        • nginx as web server (preferably used as facade server in production environment)
        • SSLMate (using OpenSSL) for certificate management
        • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
        • PostgreSQL as preferred database system
        • Redis as preferred in-memory database/store (great for caching)

        The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

        • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
        • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
        • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
        • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
        • Scalability: All-in-one framework for distributed systems.
        • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
        See more
        Riak logo

        Riak

        104
        136
        44
        A distributed, decentralized data storage system
        104
        136
        + 1
        44
        PROS OF RIAK
        • 14
          High Performance
        • 11
          High Availability
        • 9
          Easy Scalability
        • 5
          Flexible
        • 1
          Strong Consistency
        • 1
          Eventual Consistency
        • 1
          Distributed
        • 1
          Multi datacenter deployments
        • 1
          Reliable
        CONS OF RIAK
          Be the first to leave a con

          related Riak posts

          Gokhan Boranalp
          General Manager at Zetaops · | 1 upvote · 75 views
          Shared insights
          on
          FlaskFlaskErlangErlangRiakRiak
          at

          Stackshare guys/gals what are you trying to do by adding this "Stack Profile strength: Basic " to our profile. Basically it is BS and unnecessary measurement method. Checkout the jewels we are working with Flask Erlang Riak and more.

          See more
          Cassandra logo

          Cassandra

          3.6K
          3.5K
          507
          A partitioned row store. Rows are organized into tables with a required primary key.
          3.6K
          3.5K
          + 1
          507
          PROS OF CASSANDRA
          • 119
            Distributed
          • 98
            High performance
          • 81
            High availability
          • 74
            Easy scalability
          • 53
            Replication
          • 26
            Reliable
          • 26
            Multi datacenter deployments
          • 10
            Schema optional
          • 9
            OLTP
          • 8
            Open source
          • 2
            Workload separation (via MDC)
          • 1
            Fast
          CONS OF CASSANDRA
          • 3
            Reliability of replication
          • 1
            Size
          • 1
            Updates

          related Cassandra posts

          Thierry Schellenbach
          Shared insights
          on
          GolangGolangPythonPythonCassandraCassandra
          at

          After years of optimizing our existing feed technology, we decided to make a larger leap with 2.0 of Stream. While the first iteration of Stream was powered by Python and Cassandra, for Stream 2.0 of our infrastructure we switched to Go.

          The main reason why we switched from Python to Go is performance. Certain features of Stream such as aggregation, ranking and serialization were very difficult to speed up using Python.

          We’ve been using Go since March 2017 and it’s been a great experience so far. Go has greatly increased the productivity of our development team. Not only has it improved the speed at which we develop, it’s also 30x faster for many components of Stream. Initially we struggled a bit with package management for Go. However, using Dep together with the VG package contributed to creating a great workflow.

          Go as a language is heavily focused on performance. The built-in PPROF tool is amazing for finding performance issues. Uber’s Go-Torch library is great for visualizing data from PPROF and will be bundled in PPROF in Go 1.10.

          The performance of Go greatly influenced our architecture in a positive way. With Python we often found ourselves delegating logic to the database layer purely for performance reasons. The high performance of Go gave us more flexibility in terms of architecture. This led to a huge simplification of our infrastructure and a dramatic improvement of latency. For instance, we saw a 10 to 1 reduction in web-server count thanks to the lower memory and CPU usage for the same number of requests.

          #DataStores #Databases

          See more
          Thierry Schellenbach
          Shared insights
          on
          RedisRedisCassandraCassandraRocksDBRocksDB
          at

          1.0 of Stream leveraged Cassandra for storing the feed. Cassandra is a common choice for building feeds. Instagram, for instance started, out with Redis but eventually switched to Cassandra to handle their rapid usage growth. Cassandra can handle write heavy workloads very efficiently.

          Cassandra is a great tool that allows you to scale write capacity simply by adding more nodes, though it is also very complex. This complexity made it hard to diagnose performance fluctuations. Even though we had years of experience with running Cassandra, it still felt like a bit of a black box. When building Stream 2.0 we decided to go for a different approach and build Keevo. Keevo is our in-house key-value store built upon RocksDB, gRPC and Raft.

          RocksDB is a highly performant embeddable database library developed and maintained by Facebook’s data engineering team. RocksDB started as a fork of Google’s LevelDB that introduced several performance improvements for SSD. Nowadays RocksDB is a project on its own and is under active development. It is written in C++ and it’s fast. Have a look at how this benchmark handles 7 million QPS. In terms of technology it’s much more simple than Cassandra.

          This translates into reduced maintenance overhead, improved performance and, most importantly, more consistent performance. It’s interesting to note that LinkedIn also uses RocksDB for their feed.

          #InMemoryDatabases #DataStores #Databases

          See more