While Decker's UI is primarily black and white, internally it uses a 16-color palette. You can draw with any of these colors on a card background by switching to "color mode" (Style -> Color). The palette is customizable, and there has been some previous discussion about importing color images.

Decks are, in a real sense, databases already, with grid widgets serving as reified tables and Lil offering a SQL-ish query language. There are no hard limits to the quantity of data which can be stored in a grid widget; tens of thousands of rows and a few dozen columns should be no trouble at all. With a huge dataset your mileage may vary, but you can always give it a shot.

Decker does not directly integrate with SQLite, but there are a few options. If you simply want to synchronize the contents of a deck with a SQLite database, you could use a Lilt script to automate exporting information from a deck or importing data and programmatically building a deck from it. If you're comfortable building Decker from source you could alternatively use The Danger Zone to communicate with other software live.

Decker can readily work with a variety of common data interchange formats like CSV, JSON, or XML, and it does have facilities for parsing binary formats.  There aren't currently any libraries for working with SQLite's database format, but it would certainly be possible for a sufficiently motivated individual to write one in Lil.