So far, the argument leads to nothing, except for accusations that bring us no closer to any solution. But okay ... let's just continue with that. > Why not? If a better schema design would solve the speed problem, then it's a fair target for criticism. Maybe. But if a possible solution (currently) not affordable, I have to seek for an other. > Realize however that SQLite cannot be so optimized until the developers have a reproducible test case, which you haven't provided. What does "reproducible" means for you? Why don't you feel able to execute the code above and get comparable results? Did you notice that the code above should run everywhere without any requirements except Visual Studio and the SQLite.net-library? > is the query just as slow from the sqlite3 command shell? Did you see any query in "SQLiteCommandBuilder.GetInsertCommand" which could be executed in the sqlite3 command shell? I don't. And without investigating the source code of SQLiteCommandBuilder myself I will not be able to know, what happens in there. So ... asking somebody who knows the source code should be a valid way, don't you think so? If the developers are of the opinion that it is not worth pursuing, then I can still familiarize myself with the source code or develop my own CommandBuilder or work around. > If it's fast, then the problem's in Microsoft's .NET class, not in SQLite, so this isn't the right place to report it. All CommandBuilders (MSSql, Access, MySQL, SQLite) inherit from Microsoft's DbCommandBuilder. 3 of them run fast, 1 comparatively slow. Do you really believe it makes sense to investigate Microsofts part first? **AddOn:** Oh ... I missed, you wrote "Microsoft.Data.Sqlite". I don't use the "Microsoft.Data.SQLite" components, I use only the "System.Data.SQLite" components from the mentioned "SQLite-netFx46-static-binary-x64-2015-1.0.112.0"-Library. But: as all ado.net components also these components inherits from Microsofts "System.Data.Common".