Is there any scenario where a exported (.sql) database dump could be bigger in size, than the database itself? I'm a developer in a local company, and I'm currently working on a project which involves migrating a website to my company's server, from some other hosting provider.

For some reason this other company won't give us access to the cPanel, but rather provided us with the project (files) and an exported db script(.sql).

Now I'm having issues after importing the db because it lacks few tables.
I actually think the db export is okay itself. While the script file is rather large ~1.5GB, the db after importing is only ~1GB.

Q:

I'm using cPanel &amp; phpMyAdmin, and now I'm wondering if there's any scenario where the db SQL script file could be larger than the database itself, or might there be a limitation within cPanel or phpMyAdmin regarding the size, which would cause the import to skip/stop or anything similar on about 1GB?

I always thought (and still think it makes more sense) that the db could be only bigger than the script file, due to how the SQL scripts are built, lack of indexes etc.

Just wanted to check if this is possible, before I start inspecting the 1.5GB sql file myself and see wether tables are missing there too.

Thanks PS couldn't find similar questions.
Lots of cases...


VARCHAR needs 1 or 2 extra bytes for the length; as text it needs two quotes, a comma, and possibly some escape characters.
The BIGINT 123456789012345 takes 8 bytes in the table, but 16 in the dump (15 digits, plus a comma).
A NULL value dumps as 5 bytes, regardless of what the datatype needs, which is probably 0.
DECIMAL(11,2) with -123456789.12:  5 bytes in the table -> 14 bytes in the dump
(and the DATETIME/TIMESTAMP example given in a Comment)


Going the other direction:


BIGINT 1:  8 bytes -> 2
CHAR(100) 'x':  100 characters -> 4 bytes.  (This example varies with charset, version and engine.)
DECIMAL(11,0) with 0:  4 bytes in the table -> 2 bytes (0,) in the dump


Etc.