System.Data.SQLite

System.Data.SQLite.SQLiteConnection.SetupSQLiteBase(SortedList<TKey, TValue>)
System.Data.SQLite.SQLiteConnection.Open()

using (var conn = new SQLiteConnection("Data Source=" + fullPathName + ";Version=3;" + (sharedMode ? "cache=shared" : string.Empty)))
{
    conn.Open();
    conn.Insert(row);
}

Connection objects should be disposed.  It's a bit more complex than the
typical IDisposable pattern due to things like connection pooling.  This
behavior should be tested pretty thoroughly by the test suite; however,
just to be completely sure, I will double check the expected behavior
manually.

I looked at your example project and I strongly suspect is that Dapper is
somehow keeping the connection open past the end of the using block, e.g.
via not disposing of one or more SQLiteCommand and/or SQLiteDataReader
objects.

Using the following code of yours, slightly modified, appears to show the connections being properly closed. Aside: I have another variant of this without Dapper which also shows the connections being properly closed.

  using System.Data.SQLite;
  using System.Diagnostics;
  using System.Runtime.CompilerServices;
  using Dapper.Contrib.Extensions;

  string fullPathName = Path.Combine(
      AppDomain.CurrentDomain.BaseDirectory, "mydb.sqlite");

  const string tableScript = @"CREATE TABLE IF NOT EXISTS MyTable (
      [Id] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
      Value INTEGER
      );";

  void CreateDB()
  {
      var fileInfo = new FileInfo(fullPathName);
      if (fileInfo.Exists)
      {
          fileInfo.Delete();
      }
      SQLiteConnection.CreateFile(fullPathName);
      using (var conn = new SQLiteConnection(
          "Data Source=" + fullPathName + ";Version=3;"))
      {
          conn.Open();
          var command = new SQLiteCommand(tableScript)
          {
              Connection = conn
          };
          using (command)
          {
              command.ExecuteNonQuery();
          }
      }
  }

  void SQLiteConnection_Changed(object sender, ConnectionEventArgs e)
  {
      if ((e.EventType == SQLiteConnectionEventType.Opened) ||
          (e.EventType == SQLiteConnectionEventType.Closed))
      {
          Console.WriteLine(String.Format("{0} {1}",
              RuntimeHelpers.GetHashCode(sender), e.EventType));
      }
  }

  void Main()
  {
      SQLiteConnection.Changed += new SQLiteConnectionEventHandler(
          SQLiteConnection_Changed);

      CreateDB();

      var watch = Stopwatch.StartNew();
      for(var i=0; i<10000; i++)
      {
          using (var conn = new SQLiteConnection(
              "Data Source=" + fullPathName + ";Version=3;"))
          {
              conn.Open();
              conn.Insert(new MyTable(){Value = 1});
          }
      }
      watch.Stop();
      Console.WriteLine($"took {watch.ElapsedMilliseconds/1000.0}s");
  }

  Main();

for(var i=0; i<100000; i++)
{
    using (var conn = new SQLiteConnection(
               "Data Source=" + fullPathName + ";Version=3;"))
    {
        conn.Open();
        //conn.Insert(new MyTable(){Value = 1});
    }
}

Thanks for the additional information.

The underlying (native) resources associated with a SQLiteConnection do
get disposed when the connection is closed unless connection pooling is
enabled.

It sounds like your primary concern is the finalizer queue.  I think your
idea of using the GC.SuppressFinalize method is correct.  The code should
be doing that when it gets done cleaning up the underlying CriticalHandle
and its associated native resources.

I will work on adding that and the necessary tests.

Thanks again for the report.

The fix for this is now on trunk, complete with tests.