What is MySQL?
What is Oracle?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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.
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.
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.
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.
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.
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.
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:
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 :)
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!
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
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:
- And more not yet defined....
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.
I would like to build a medium to large scale app, that has real-time operations and a good authentication system and a secure and fast API. Should I use Django with React only? Or maybe use Django for the API, Node.js for real-time operations and React for the frontend? Any suggestions? Which database should I use with those technologies? Should I use both MySQL / PostgreSQL and MongoDB together? Should I use only MongoDB or MySQL / PostgreSQL? Or is it better to go with both MySQL and PostgreSQL at the same time? Should I use also GraphQL?
I am a Microsoft SQL Server programmer who is a bit out of practice. I have been asked to assist on a new project. The overall purpose is to organize a large number of recordings so that they can be searched. I have an enormous music library but my songs are several hours long. I need to include things like time, date and location of the recording. I don't have a problem with the general database design. I have two primary questions:
- I need to use either MySQL or PostgreSQL on a Linux based OS. Which would be better for this application?
- I have not dealt with a sound based data type before. How do I store that and put it in a table? Thank you.
Well, I want to build a large-scale project, but I do not know which ORDBMS to choose. The app should handle real-time operations, not chatting, but things like future scheduling or reminders. It should be also really secure, fast and easy to use. And last but not least, should I use them both. I mean PostgreSQL with Python / Django and MongoDB with Node.js? Or would it be better to use PostgreSQL with Node.js?
*The project is going to use React for the front-end and GraphQL is going to be used for the API.
Thank you all. Any answer or advice would be really helpful!
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.
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 arcane and old fashioned at first, but the developers have clearly shown that they understand databases and the storage trends better than almost anyone else. It definitely deserves to be part of everyone's toolbox; when you find yourself needing rock solid performance, operational simplicity and reliability, reach for PostgresQL.
Relational data stores solve a lot of problems reasonably well. Postgres has some data types that are really handy such as spatial, json, and a plethora of useful dates and integers. It has good availability of indexing solutions, and is well-supported for both custom modifications as well as hosting options (I like Amazon's Postgres for RDS). I use HoneySQL for Clojure as a composable AST that translates reliably to SQL. I typically use JDBC on Clojure, usually via org.clojure/java.jdbc.
We are used MySQL database to build the Online Food Ordering System
- Its best support normalization and all joins ( Restaurant details & Ordering, customer management, food menu, order transaction & food delivery).
- Best for performance and structured the data.
- Its help to stored the instant updates received from food delivery app ( update the real-time driver GPS location).
1.It's very popular. Heared about it in Database class 2. The most comprehensive set of advanced features, management tools and technical support to achieve the highest levels of MySQL scalability, security, reliability, and uptime. 3. MySQL is an open-source relational database management system. Its name is a combination of "My", the name of co-founder Michael Widenius's daughter, and "SQL", the abbreviation for Structured Query Language.
We use MySQL and variants thereof to store the data for our projects such as the community. MySQL being a well established product means that support is available whenever it is required along with an extensive list of support articles all over the web for diagnosing issues. Variants are also used where needed when, for example, better performance is needed.
PostgreSQL is responsible for nearly all data storage, validation and integrity. We leverage constraints, functions and custom extensions to ensure we have only one source of truth for our data access rules and that those rules live as close to the data as possible. Call us crazy, but ORMs only lead to ruin and despair.
MySQL is a freely available open source Relational Database Management System (RDBMS) that uses Structured Query Language (SQL). SQL is the most popular language for adding, accessing and managing content in a database. It is most noted for its quick processing, proven reliability, ease and flexibility of use.
Tried MongoDB - early euphoria - later dread. Tried MySQL - not bad at all. Found PostgreSQL - will never go back. So much support for this it should be your first choice. Simple local (free) installation, and one-click setup in Heroku - lots of options in terms of pricing/performance combinations.
I am not using this DB for blog posts or data stored on the site. I am using to track IP addresses and fully qualified domain names of attacker machines that either posted spam on my website, pig flooded me, or had more that a certain number of failed SSH attempts.
Gerenciamento de banco de dados utilizados por odos os serviços/aplicações criados
recommended solution at school, also used to try out alternatives to MySQL