In the first version, the remote server must be a MySQL server. Support by FEDERATED for other database engines may be added in the future.

The remote table that a FEDERATED table points to must exist before you try to access the table through the FEDERATED table.

It is possible for one FEDERATED table to point to another, but you must be careful not to create a loop.

There is no support for transactions.

Performance on a FEDERATED table when performing bulk inserts (for example, on a INSERT INTO ... SELECT ... statement) is slower than with other table types because each selected row is treated as an individual INSERT statement on the federated table.

There is no way for the FEDERATED engine to know if the remote table has changed. The reason for this is that this table must work like a data file that would never be written to by anything other than the database. The integrity of the data in the local table could be breached if there was any change to the remote database.

The FEDERATED storage engine supports SELECT, INSERT, UPDATE, DELETE, and indexes. It does not support ALTER TABLE, or any Data Definition Language statements other than DROP TABLE. The current implementation does not use Prepared statements.

Any DROP TABLE statement issued against a FEDERATED table will only drop the local table, not the remote table.

The implementation uses SELECT, INSERT, UPDATE, and DELETE, but not HANDLER.

FEDERATED tables do not work with the query cache.