HBase vs MySQL vs PostgreSQL

Get Advice Icon

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

HBase
HBase

217
185
+ 1
12
MySQL
MySQL

28.3K
22.7K
+ 1
3.7K
PostgreSQL
PostgreSQL

20.8K
16.5K
+ 1
3.4K

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

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 HBase?
Why do developers choose MySQL?
Why do developers choose PostgreSQL?

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

    Be the first to leave a con
    What companies use HBase?
    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 HBase?
    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 HBase, MySQL, and PostgreSQL?
    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.
    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.
    Hadoop
    The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage.
    Druid
    Druid is a distributed, column-oriented, real-time analytics data store that is commonly used to power exploratory dashboards in multi-tenant environments. Druid excels as a data warehousing solution for fast aggregate queries on petabyte sized data sets. Druid supports a variety of flexible filters, exact calculations, approximate algorithms, and other useful calculations.
    Apache Hive
    Hive facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage.
    See all alternatives
    Decisions about HBase, 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 · 75.3K 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 · 231.3K 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 · 119K 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.7K 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.1K 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
    Martin Johannesson
    Martin Johannesson
    Senior Software Developer at IT Minds · | 11 upvotes · 29.9K views
    atIT MindsIT Minds
    TypeScript
    TypeScript
    Node.js
    Node.js
    TypeORM
    TypeORM
    PostgreSQL
    PostgreSQL
    Apollo
    Apollo
    GraphQL
    GraphQL
    Next.js
    Next.js
    MongoDB
    MongoDB
    React
    React
    PWA
    PWA
    AMP
    AMP
    #B2B
    #Backend
    #Serverless

    At IT Minds we create customized internal or #B2B web and mobile apps. I have a go to stack that I pitch to our customers consisting of 3 core areas. 1) A data core #backend . 2) A micro #serverless #backend. 3) A user client #frontend.

    For the Data Core I create a backend using TypeScript Node.js and with TypeORM connecting to a PostgreSQL Exposing an action based api with Apollo GraphQL

    For the micro serverless backend, which purpose is verification for authentication, autorization, logins and the likes. It is created with Next.js api pages. Using MongoDB to store essential information, caching etc.

    Finally the frontend is built with React using Next.js , TypeScript and @Apollo. We create the frontend as a PWA and have a AMP landing page by default.

    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
    Bryam Rodriguez
    Bryam Rodriguez
    JavaScript
    JavaScript
    Bit
    Bit
    Python
    Python
    Next.js
    Next.js
    React Native
    React Native
    Redis
    Redis
    MongoDB
    MongoDB
    PostgreSQL
    PostgreSQL