Written by Dan Parry.
Database Management Systems (DBMS), in short, are collections of tools used to access and manipulate the data stored in a da...
For further actions, you may consider blocking this person and/or reporting abuse
Generally speaking, just use postgres, it'll be fine. There are many ways to optimize for speed but the limits of MySQL are significant and will likely eventually come to bite you.
SQLite is good for native app local storage and also I think it's really a good way to transfer data in some use cases.
I agree that the real options are SQLite and Postgres. If you want SQL database for offline use in a single app, SQLite is the way to go. For everything else you should pick up Postgres.
The whole point of MySQL and MariaDB is backwards compatibility. New projects should not start with either.
Sqlite might also be an option in some online cases. But yeah postgres is usually the way to go.
yep I agree SQLite for little in app stuff, and Postres for all the rest, but if I am forced to use the MySQl/MariaDB route then MariaDB is better, it keeps you out of clutches of Oracle
I've used both MySQL and Postgres, and somewhat prefer postgres nowadays. Though I'm not sure what you mean by "limits of MySQL are significant". In what way is it so significantly different? At my last job the I saw MySQL being used housing tens of thousands of tables, some of which having billions of records and over a petabyte of production data being used to analyze marketing metrics. Honestly just curious: what are the limits? I don't have any evidence to say what the limits to MySQL are.
Well. I won't give a comprehensive list. But list a few examples that should give you an idea of what I'm talking about. Until MySQL 8.0 there wasn't even support for any window functions. In 8.0 there's minimal support for window functions. There's no support for row level security. Upsert constraints are reduced to INSERT or REPLACE (which is dicey).
So more of a functional limitation rather than a scalability one then right?
Extending on Jacob's points, one that I find inexcusable (and has in fact hit me in the face a few moments ago at work) is the fact that MySQL does not support Transactional DDL and only supports Atomic DDL starting from 8.0. Whereas both PostgreSQL and SQLite support this.
To specify it's significance for those unaware: say your application manages migrations and needs to do several steps in one go (e.g. alter some column name and some data modification), you should be able to start a transaction and run all steps. If something goes wrong (e.g. the application is somehow terminated mid-migration, as happened here), then all migration steps are perfectly reverted. Hence it will be completely ready for a new apply, or, you can go back to the old version of the software and you know the database should be in a state as if there was no update whatsoever.
Yes, this can be alleviated by making a backup before upgrading, which we did, but it's also demonstrated by two systems, one of which (SQLite) I always saw as a simplistic database, that it can be done. I can kill the application modifying the schema of an SQLite database without any ill effects.
For offline first web apps sqllite-worker is worth consideration as well.
Thanks, not familiar but I'll take a look!
I'm thinking of doing an app with RedwoodJS, and use Postgres for everything.
good to know, thanks for the insight!
This is seen as a good thing? 🙈
Joking aside, I think Oracle has done a reasonable job maintaining MySQL. Given the choice between MySQL and MariaDB, its Oracle-free competitor, I would still choose MariaDB over MySQL though, because it’s better in almost every way.
Interesting take, will look into MariaDB :)
It's astonishing how far Postgres has come since the 8.0 era, circa 2005. A lot of the arguments about it being "more complicated" and "lacking tools" are falling away as it gains more and more traction.
If you don't like Postgres enough to switch away from MySQL today, give it a few years and you'll have even more reasons.
Really love what the Postgres team has done over the last decade and a half. It's astonishing the progress they've made.
One other point about MySQL is that it fell into Oracle's lap with their acquisition of Sun Microsystems in 2009. Given Oracle's regular commercial shenanigans it wouldn't be too surprising if there are directives in place to ensure that MySQL never becomes a serious competitor to their own in-house RDBMS product.
Now granted there is MariaDB as a fallback if the unthinkable happens — however personally for me there is enough there to bypass MySQL entirely and go straight to PostgreSQL.
(Amazon put in a significant effort which finally in October 2019 resulted in their business shedding the last of its dependencies on Oracle — a move that had little to do with "Dogfooding").
I think SQLite and PostgreSQL are significantly different, other than embedded vs server.
SQLite - much less feature-rich; much smaller, suitable for embedded; add functions in the driver of language of your choice
PostgreSQL - more features; write functions into SQL, or that can compile for Postgres; comply to 12-factor app
Some time ago, I was also recommended firebird; but I dropped it, because of no full text search (FTS) support.
If I remembered correctly, at least Firebird, Neo4j and CouchDB have this dual nature.
Depends how you define 'popular'. SQLite is by far the most widely-deployed RDBMS, by orders of magnitude: sqlite.org/mostdeployed.html
Fine, I meant just my favorite :D
Good article. Thanks for sharing. i trust postgres
Good article. Thanks for sharing
Great article. Thanks for sharing.
Thanks! Glad to hear that
Informative article. Thanks for putting the time to write it.
Thanks! Glad you enjoyed it.