The benefits of ALGORITHM=INPLACE in ALTER TABLE queries For some reason I can't find any information on this.
A colleague insists me to use that on an Alter Table query but can't really say why.
It is a small table concerning the application's basic configurations with a very small amount of rows.
What are the benefits of ALGORITHM=INPLACE in a query that adds one MEDIUMINT NOT NULL type of column to a table which will have 10 rows at most?
The database is MySql.
A 10-row alter will be so fast that the &quot;Algorithm&quot; won't make a noticeable difference.  You probably won't see a diff for 1000 rows.
Some history:
Originally ALTER had exactly one way of being performed under the hood.  This made the code easy, but the performance not as good as it could be.

Create a new table like the existing table
make the modifications to that empty table
INSERT ... SELECT ... to copy all the data over
Juggle table names and drop the old data.

Beginning with 5.6, there was a concerted effort to optimize specific cases -- mostly to avoid the full table copy.  This led to a variety of syntaxes and options.  Confusing.
Fortunately, if you ask for an algorithm that is not applicable to the action in question, it will spit at you.  Simply change the algorithm and try again.
I think, without proof, that ALTER TABLE will use the best Algorithm available for the use case in hand.  And the Algorithm options are there in case something goes wrong and you need to force a different algorithm.
So why have ALGORITHM?  I think it is like a lot of VARIABLES -- if something goes wrong, the end-user has the ability to &quot;fix&quot; the problem by turning off something.  This does come into play in various evaluation optimzations.  A visible case is FORCE INDEX.
Alas, the documentation of ALGORITHM is wimpy.