Couchbase vs MySQL vs PostgreSQL

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Couchbase
Couchbase

225
215
+ 1
56
MySQL
MySQL

28.5K
22.9K
+ 1
3.7K
PostgreSQL
PostgreSQL

21K
16.7K
+ 1
3.4K
- No public GitHub repository available -

What is 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.

What is MySQL?

The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software.

What is PostgreSQL?

PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose Couchbase?
Why do developers choose MySQL?
Why do developers choose PostgreSQL?

Sign up to add, upvote and see more prosMake informed product decisions

What companies use Couchbase?
What companies use MySQL?
What companies use PostgreSQL?

Sign up to get full access to all the companiesMake informed product decisions

What tools integrate with Couchbase?
What tools integrate with MySQL?
What tools integrate with PostgreSQL?

Sign up to get full access to all the tool integrationsMake informed product decisions

What are some alternatives to Couchbase, MySQL, and PostgreSQL?
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.
CouchDB
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.
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.
Redis
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
HBase
Apache HBase is an open-source, distributed, versioned, column-oriented store modeled after Google' Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, HBase provides Bigtable-like capabilities on top of Apache Hadoop.
See all alternatives
Decisions about Couchbase, MySQL, and PostgreSQL
StackShare Editors
StackShare Editors
PostgreSQL
PostgreSQL
MySQL
MySQL

In 2014, Uber began working on Big Data Generation 1. Prior to 2014, all of the company’s data could fit into “a few traditional online transaction processing (OLTP) databases (in [their] case, MySQL and PostgreSQL ).” At that time, engineers were required to write individual code to access and join data across databases, a take made more difficult by the fact that there was no global view of all stored data, which was scattered around several OLTP databases with a “total data size on the order of a few terabytes.”

They chose Vertica as the analytical data warehouse, because of “because of its fast, scalable, and column-oriented design. We also developed multiple ad hoc ETL (Extract, Transform, and Load) jobs that copied data from different sources (i.e. AWS S3, OLTP databases, service logs, etc.) into Vertica.

See more
StackShare Editors
StackShare Editors
PostgreSQL
PostgreSQL
MySQL
MySQL

Uber's early architecture was a monolithic Python backend on top of Postgres. Between 2014 and 2016, Uber moved many applications off of Postgres and onto MySQL, accessed through a sharding layer built in-house called Schemaless.

As the company scaled, Uber encountered issues with scaling writes due to write amplification issues (1 logical write causing 4 physical writes) and inefficient data replication with Postgres. Postgres replication works at the physical level, which means that it's not possible to replicate data between data bases running different versions. This added complexity and risk to upgrades.

MySQL, and the InnoDB storage engine in particular, can do replication at the statement level, which poses less risks and works between versions. Uber also found MySQL's caching and connection pooling capabilities to provide superior performance for their use cases.

See more
Jake Stein
Jake Stein
CEO at Stitch · | 15 upvotes · 76K views
atStitchStitch
Clojure
Clojure
MySQL
MySQL
PostgreSQL
PostgreSQL

The majority of our Clojure microservices are simple web services that wrap a transactional database with CRUD operations and a little bit of business logic. We use both MySQL and PostgreSQL for transactional data persistence, having transitioned from the former to the latter for newer services to take advantage of the new features coming out of the Postgres community.

Most of our Clojure best practices can be summed up by the phrase "keep it simple." We avoid more complex web frameworks in favor of using the Ring library to build web service routes, and we prefer sending SQL directly to the JDBC library rather than using a complicated ORM or SQL DSL.

See more
Gregory Koberger
Gregory Koberger
MongoDB
MongoDB
MySQL
MySQL
PostgreSQL
PostgreSQL
MongoDB Atlas
MongoDB Atlas
MongoLab
MongoLab
Compose
Compose

We went with MongoDB , almost by mistake. I had never used it before, but I knew I wanted the *EAN part of the MEAN stack, so why not go all in. I come from a background of SQL (first MySQL , then PostgreSQL ), so I definitely abused Mongo at first... by trying to turn it into something more relational than it should be. But hey, data is supposed to be relational, so there wasn't really any way to get around that.

There's a lot I love about MongoDB, and a lot I hate. I still don't know if we made the right decision. We've been able to build much quicker, but we also have had some growing pains. We host our databases on MongoDB Atlas , and I can't say enough good things about it. We had tried MongoLab and Compose before it, and with MongoDB Atlas I finally feel like things are in a good place. I don't know if I'd use it for a one-off small project, but for a large product Atlas has given us a ton more control, stability and trust.

See more
Anton Sidelnikov
Anton Sidelnikov
Backend Developer at Beamery · | 8 upvotes · 9.8K views
PostgreSQL
PostgreSQL
MongoDB
MongoDB

In my opinion PostgreSQL is totally over MongoDB - not only works with structured data & SQL & strict types, but also has excellent support for unstructured data as separate data type (you can store arbitrary JSONs - and they may be also queryable, depending on one of format's you may choose). Both writes & reads are much faster, then in Mongo. So you can get best on Document NoSQL & SQL in single database..

Formal downside of PostgreSQL is clustering scalability. There's not simple way to build distributed a cluster. However, two points:

1) You will need much more time before you need to actually scale due to PG's efficiency. And if you follow database-per-service pattern, maybe you won't need ever, cause dealing few billion records on single machine is an option for PG.

2) When you need to - you do it in a way you need, including as a part of app's logic (e.g. sharding by key, or PG-based clustering solution with strict model), scalability will be very transparent, much more obvious than Mongo's "cluster just works (but then fails)" replication.

See more
Tim Abbott
Tim Abbott
Founder at Zulip · | 22 upvotes · 236.2K views
atZulipZulip
PostgreSQL
PostgreSQL
MySQL
MySQL
Elasticsearch
Elasticsearch

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

See more
Conor Myhrvold
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 12 upvotes · 145.4K views
atUber TechnologiesUber Technologies
PostgreSQL
PostgreSQL
MySQL
MySQL
Python
Python

Our most popular (& controversial!) article to date on the Uber Engineering blog in 3+ yrs. Why we moved from PostgreSQL to MySQL. In essence, it was due to a variety of limitations of Postgres at the time. Fun fact -- earlier in Uber's history we'd actually moved from MySQL to Postgres before switching back for good, & though we published the article in Summer 2016 we haven't looked back since:

The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL (https://eng.uber.com/schemaless-part-one/). In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL:

https://eng.uber.com/mysql-migration/

See more
Alex A
Alex A
Founder at PRIZ Guru · | 6 upvotes · 8.8K views
atPRIZ GuruPRIZ Guru
MySQL
MySQL
PostgreSQL
PostgreSQL

One of our battles at the very beginning of the road was choosing the right database. In fact, our first prototype was built on MySQL and back then nothing else was even under a consideration (don't ask me why). At some point, I was working on a project which was running on PostgreSQL and it is only then I understood the full power of it. We have over a billion of records in production instance, and we are able to optimize it to run fast and reliable. Well, now my default DB is PostgreSQL :)

See more
Tor Hagemann
Tor Hagemann
at Socotra · | 2 upvotes · 2.3K views
atSocotraSocotra
MySQL
MySQL
PostgreSQL
PostgreSQL
Amazon DynamoDB
Amazon DynamoDB

Much of our data model is relational, which makes MySQL or PostgreSQL (and family) fit the API's we need to build, in order to meet the needs of our customers.

Sometimes the flexibility of a NoSQL store like Amazon DynamoDB is very useful, but the lack of consistency really impacts usability and performance long-term, compared with viable alternatives. At our current scale, we've seen huge benefits from moving some of our tables out of Dynamo and doing more in SQL.

There will always be use cases for NoSQL and key-values stores, but if your model is well understood in your business/industry: relational databases are the way to go after finding product-market fit. Always understand the trade-offs (and a few intimate details) of any data store before you add to your company's stack!

See more
Joseph Irving
Joseph Irving
DevOps Engineer at uSwitch · | 8 upvotes · 10.2K views
atUswitchUswitch
Vault
Vault
Kubernetes
Kubernetes
MySQL
MySQL
PostgreSQL
PostgreSQL
Go
Go

At uSwitch we use Vault to generate short lived database credentials for our applications running in Kubernetes. We wanted to move from an environment where we had 100 dbs with a variety of static passwords being shared around to a place where each pod would have credentials that only last for its lifetime.

We chose vault because:

  • It had built in Kubernetes support so we could use service accounts to permission which pods could access which database.

  • A terraform provider so that we could configure both our RDS instances and their vault configuration in one place.

  • A variety of database providers including MySQL/PostgreSQL (our most common dbs).

  • A good api/Go -sdk so that we could build tooling around it to simplify development worfklow.

  • It had other features we would utilise such as PKI

See more
Jelena Dedovic
Jelena Dedovic
Tornado
Tornado
asyncio
asyncio
AIOHTTP
AIOHTTP
PostgreSQL
PostgreSQL
MSSQL
MSSQL

Investigating Tortoise ORM and GINO ORM...

I need to introduce some async ORM with the current stack: Tornado with asyncio loop, AIOHTTP, with PostgreSQL and MSSQL. This project revolves heavily around realtime and due to the realtime requirements, blocking during database access is not acceptable.

Considering that these ORMs are both young projects, I wondered if anybody had some experience with similar stack and these async ORMs?

See more
C#
C#
.NET Core
.NET Core
MySQL
MySQL
MongoDB
MongoDB

Hi! I needed to choose a full stack of tools for a web drop shipping site without the payment process for a family startup proyect. It will feed from several web services (JSON), I'm looking forward a 4,200 articles tops. For web use only and for a few clients at the beginning.

I'm considering C# with .NET Core 3.0 as is the one language I'm starting to learn. For the Database I haven´t made my mind yet, but could be MySQL or MongoDB any advice is welcome as I'm getting back to programming after year away from this awesome world. Thanks

See more
Nicolas Apx
Nicolas Apx
CEO - FullStack Javascript at Apx Development Limited · | 14 upvotes · 33.3K views
atAPX DevelopmentAPX Development
Python
Python
Node.js
Node.js
MongoDB
MongoDB
PostgreSQL
PostgreSQL

I am planning on building a micro-service eCommerce back-end to be easy to reuse in any project as we need. I would like to use both Python and Node.js and MongoDB & PostgreSQL , in your opinion which one would best suited for the following services:

  • Users-service
  • Products-service
  • Auth-service
  • Inventory-service
  • Order-service
  • Payment-service
  • Sku-service
  • And more not yet defined....

Thanks

Nicolas

See more
Gabriel Pa
Gabriel Pa
CEO at NaoLogic Inc · | 6 upvotes · 97.3K views
atNaologicNaologic
Memcached
Memcached
Couchbase
Couchbase
CouchDB
CouchDB

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
Bryam Rodriguez
Bryam Rodriguez
JavaScript
JavaScript
Bit
Bit
Python
Python
Next.js
Next.js
React Native
React Native
Redis
Redis
MongoDB
MongoDB
PostgreSQL
PostgreSQL
RSpec
RSpec
react-testing-library
react-testing-library
Jest
Jest
Create React App
Create React App
Redux
Redux
React
React
Rails
Rails
Ruby
Ruby

I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.

We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

See more
Interest over time
Reviews of Couchbase, MySQL, and PostgreSQL
No reviews found
How developers use Couchbase, MySQL, and PostgreSQL
Avatar of AngeloR
AngeloR uses PostgreSQLPostgreSQL

We use postgresql for the merge between sql/nosql. A lot of our data is unstructured JSON, or JSON that is currently in flux due to some MVP/interation processes that are going on. PostgreSQL gives the capability to do this.

At the moment PostgreSQL on amazon is only at 9.5 which is one minor version down from support for document fragment updates which is something that we are waiting for. However, that may be some ways away.

Other than that, we are using PostgreSQL as our main SQL store as a replacement for all the MSSQL databases that we have. Not only does it have great support through RDS (small ops team), but it also has some great ways for us to migrate off RDS to managed EC2 instances down the line if we need to.

Avatar of Cloudcraft
Cloudcraft uses PostgreSQLPostgreSQL

PostgreSQL combines the best aspects of traditional SQL databases such as reliability, consistent performance, transactions, querying power, etc. with the flexibility of schemaless noSQL systems that are all the rage these days. Through the powerful JSON column types and indexes, you can now have your cake and eat it too! PostgreSQL may seem a bit arc