I strongly disagree with @hwillson.
My business embraced Meteor in early 2015. Since then, we have been using it with MySQL for our webapps and it works beautifully.
Originally, we chose to use MySQL instead of MongoDB for interoperability with our legacy LAMP-based solutions, but since those were retired, we have continued to use MySQL with Meteor on its own merits. Please search the forums for my previous posts where I have written at length.
We have also been actively developing the wj32:mysql and vlasky:mysql forks of Ben Green’s numtel:mysql package.
These packages differ in the way that they handle the data, but all of us developers collaborate with each other.
numtel:mysql treats MySQL result sets as arrays and uses an array-based diff algorithm for updates.
wj32:mysql was worked on mainly by one our developers named Wen Jia. It treats MySQL result sets as dictionaries and uses a user-defined key selector algorithm. On the client side, data can be stored in the standard MongoCollection.
vlasky:mysql is my experimental fork of Wen Jia’s package, in which I have replaced the older node-mysql library with the newer node-mysql2 library, which supports prepared statements and offers higher performance.
I see the prepared statement functionality offering the following benefits for Meteor/NodeJS:
- Avoiding the overhead of MySQL parsing, resolution and some optimization on the frequently repeated queries used for publications.
- Providing immunity to SQL injection (current approach of argument escaping is resistant, but not immune)
- Prepared statement results are returned in a binary format instead of text-based format, reducing the amount of data being transferred and parsed by NodeJS.
I will share more news/updates about using Meteor with MySQL as soon as I have more time.