Your question is not clear, but it seems your goal is to distribute a relatively fresh copy of your database’s data alongside the source code of your app that accesses that database. But you do not explain your motivation or goal. I imagine you either want machines to read that data, or you want people to read that data.
Either way, consider distributing the data separately from the source code. Combining them is unusual and seems confusing to me.
If your goal is convenience in establishing an instance of the database for the programmer using your source code to build and deploy for themselves, then you should include the database’s data files.
You could do this win SQLite. But beware that SQLite is indeed quite “lite”, meant more as a slightly better alternative to writing files, it is not meant to be a serious database. You have not stated the size and shape of your data, so I cannot advise if SQLite fits your needs or not.
A more serious database you might consider is the H2 Database Engine. It is written in Java, and so requires a JVM. H2 stores data to a single file that your could easily copy. H2 can run embedded within an app, or can be run separately as a database server.
If your goal is simply to let people peruse a recent copy of the data, then you need to export the data from the database to a human-readable text format.
If the goal is simply perusing, then write out web pages using basic HTML using the
table tag. And perhaps a bit of CSS. Use the programming language of your app to generate these text files.
If you want the user to make use of the data such as opening in a spreadsheet, then use a common format such as Tab-delimited (TSV) or Comma-separated Values (CSV). You might want to use a library to assist in the writing of such files, like Apache Commons CSV in Java (which also writes TSV).
You will likely want to write out one file for each table in your database. Beware of memory limits in web browsers and spreadsheet apps; you may need to break a very large table into multiple files.