Possible memory leak bug with `to_sql` with chunksize ? 
#### Code Sample, a copy-pastable example if possible

```
from sqlalchemy import create_engine
engine = sqlalchemy.create_engine("sqlite:///databasefile.db")
dataframe.to_sql("CS_table", engine, chunksize = 100)

```
#### Problem description

I created a large database in Pandas, about 6 million rows of text data. I wanted to save this as a SQL database file, but when I try to save it, I get an out of memory RAM error. I even reduced the chuck size to 100 and it still crashes. 

However, if I just have smaller version of that dataframe with 100,000 rows, and save it to a database with no chucksize specified, I have no issues saving tha dataframe. 

My understanding was that since it's only processing 100 rows at a time, the RAM usage should reflect that of a save of 100 rows. Is there something else happening behind the scenes? Perhaps multi-threading?

Before I run this code, I am using 4.8 GB RAM, out of the 12.8 GB RAM available in Google Colab. Running the above code eats up all the RAM until the enviroment crashes. 

I would like to be able to save my pandas dataframe to a SQL file without my environment crashing. The environment I am in is Google Colab. The pandas datafame is 2 columns, ~6 million rows. Each cell contains about this much text:

> "The dominant sequence transduction models are based on complex
> recurrent or convolutional neural networks in an encoder-decoder
> configuration. The best performing models also connect the encoder and
> decoder through an attention mechanism. We propose a new simple
> network architecture, the Transformer, based solely on attention
> mechanisms, dispensing with recurrence and convolutions entirely.
> Experiments on two machine translation tasks show these models to be
> superior in quality while being more parallelizable and requiring
> significantly less time to train. Our model achieves 28.4 BLEU on the
> WMT 2014 English-to-German translation task, improving over the
> existing best results, including ensembles by over 2 BLEU. On the WMT
> 2014 English-to-French translation task, our model establishes a new
> single-model state-of-the-art BLEU score of 41.8 after training for
> 3.5 days on eight GPUs, a small fraction of the training costs of the best models from the literature. We show that the Transformer
> generalizes well to other tasks by applying it successfully to English
> constituency parsing both with large and limited training data."

I posted a SO issue here

https://stackoverflow.com/questions/56369565/large-6-million-rows-pandas-df-causes-memory-error-with-to-sql-when-chunksi

And one of the users said

From stepping through the code I think it's this line, which reads creates a bunch of DataFrames

https://github.com/pandas-dev/pandas/blob/a91da0c94e541217865cdf52b9f6ea694f0493d3/pandas/io/sql.py#L676

`chunk_iter = zip(*[arr[start_i:end_i] for arr in data_list])`

Which looks like it's probably a bug. Specifically this happens prior to database insertion, in preparation.

#### Expected Output

The code should be executed without a crash. 

#### Output of ``pd.show_versions()``

<details>

[paste the output of ``pd.show_versions()`` here below this line]

INSTALLED VERSIONS
------------------
commit: None
python: 3.6.7.final.0
python-bits: 64
OS: Linux
OS-release: 4.14.79+
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

pandas: 0.24.2
pytest: 3.6.4
pip: 19.1.1
setuptools: 41.0.1
Cython: 0.29.7
numpy: 1.16.3
scipy: 1.3.0
pyarrow: 0.13.0
xarray: 0.11.3
IPython: 5.5.0
sphinx: 1.8.5
patsy: 0.5.1
dateutil: 2.5.3
pytz: 2018.9
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.9
feather: 0.4.0
matplotlib: 3.0.3
openpyxl: 2.5.9
xlrd: 1.1.0
xlwt: 1.3.0
xlsxwriter: None
lxml.etree: 4.2.6
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.3.3
pymysql: None
psycopg2: 2.7.6.1 (dt dec pq3 ext lo64)
jinja2: 2.10.1
s3fs: 0.2.1
fastparquet: None
pandas_gbq: 0.4.1
pandas_datareader: 0.7.0
gcsfs: None

</details>
