Firstly, write scaling is a hard problem. Secondly, secret to write scaling is in read scaling. That is, cache reads as much as possible, so that the writes get all the throughput.<p>Having said that, there are a bunch of things one can do:<p>1) Start with the data model. Design a data model so that you do not ever delete or update a table. Only operation is an insert. Use Effective Date, Effective Sequence and Effective Status to implement Insert, Update and Delete operations using just the Insert Command. This concept is called Append Only model. Checkout RethinkDB..<p>2) Set the Concurrent Insert flag to 1. This makes sure that the tables keep inserting while reads are in progress.<p>3) When you have only Inserts at the tail, you may not need row-level locks. So, use MyISAM (this is not to take anything away from InnoDB, which I will come to later).<p>4) If all this does not do much, create a replica table in Memory Engine. If you have a table called MY_DATA, create a table called MY_DATA_MEM in memory table.<p>5) Redirect all Inserts to the MEM table. Create a View that UNIONS both tables and use that view as your Read Source.<p>6) Write a daemon that periodically moves MEM contents to the Main table and deletes from the Mem table. It may be ideal to implement the MOVE operation as a Delete trigger on the Mem table (I am hoping triggers are possible on Memory Engine, not entirely sure).<p>7) Do not do any deletes or Updates on the MEM table (they are slow) also pay attention to the cardinality of the keys in your table (HASH vs B-Tree : Low Card -> Hash, High Card-> B-Tree)<p>8) Even if all the above does not work, ditch jdbc/odbc. Move to InnoDB and use Handler Socket interface to do the direct inserts (Google for Yoshinori-San MySQL)<p>I have not used the HS myself, but the benchmarks are impressive. There is a even Java HS Project on Google Code.<p>Hope that helps..