A Sqlite database is only one file, which you surely have access to.
So just add a Database configuration to your IDE and point it to the Sqlite file.
Click on the Database flyout on the left side then on the + (Plus) and add a Sqlite configuration.
(IntelliJ has good documentation on Sqlite Database connection as well of course)

Then you are ready to go.
The UI of the database structure is quite good.
You can browse the tables by doublelick on the table in the database structure view.
Also you can edit values in the table view.
Note: When the DB was created inside the Docker container you probably dont own the DB from the host and you wont be able write to it.
While developing just change permissions on the host, if necessary.

You can also open a Database Console window where you can test queries.
This is particular better than using Adminer because these test queries are persisted and will still be there the next day.
You can add multiple database consoles and reopen them from “Scratches and Consoles” in your Project menu.

So no Adminer needed. Sqlite is just a file, dude.
No hassles with docker-compose anymore for DB administration and still using Docker for the app. :)

Update 09.08.2023:
JetBrains has now also uploaded a nice Youtube Video Tutorial on how to deal with Sqlite databases in IntelliJ IDEs like f.e. PHPStorm:
Working with SQLite Databases in any JetBrains IDE

I learned that you can now Drag and Drop Sqlite database files into the DataBase Pane and the IDE connects it directly, nice!

Update: Today i would rather use the IntelliJ Database Tool for Sqlite administration.

But since Adminer is a popular hacking target they introduced a feature that does not allow to run adminer without a password, out of the box.
Sqlite database usually runs without password and dang, workaround needed!

So we need to add a plugin to adminer that allows password-less login and extend the official Adminer Docker image to include the plugin.

We add a script that loads the official password-less-login plugin and copy it to the plugins-enabled folder of the Adminer image

login-password-less.php:

<?php
require_once('plugins/login-password-less.php');

/** Set allowed password
 * @param string result of password_hash
 */
return new AdminerLoginPasswordLess(
    $password_hash = password_hash("admin", PASSWORD_DEFAULT)
);

Dockerfile:

FROM adminer
USER root
COPY login-password-less.php /var/www/html/plugins-enabled/login-password-less.php
#USER adminer # we run as root because of permissions problems on db file with the volume

In docker-compose.yml:

version: "3"
services:
  app:
    build: ./php
      - mailcatcher
    volumes:
      - "../:/app:rw"
      - "./php/cli/php.ini:/etc/php/7.3/cli/php.ini:ro"
      - "./php/fpm/php.ini:/etc/php/7.3/fpm/php.ini:ro"

  nginx:
    build: ./nginx
    depends_on:
      - app
    command: /bin/sh -c "nginx -g 'daemon off;'"
    volumes:
      - "..:/app:rw"
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - '8088:80'

  adminer:
    build: ./adminer
    restart: unless-stopped
    volumes:
      - "..:/app:rw"
    ports:
      - 8080:8080

File tree:

• adminer
  – Dockerfile
  – login-password-less.php
• nginx
  …
• php
  …
• docker-compose.yml

Note that since docker-compose.yml version 3 the volumes_from directive was removed in favor of top level volumes to share volumes across images. However this implementation is imho rather weird, so i jut duplicated the volumes declaration in the App container and Adminer container.
Feels rather wrong but thats all i could come up with. Any advice here is welcome.

Now that this is done we can open the Sqlite3 database with the pseudo-password “admin” and manage the database.

After all you could also just copy the one-file Adminer with plugin to the php container and run it from within the php container. Just adjust your Nginx config to allow calling the file directly and take care to not deploy Adminer to live.
There is also a project that bundles the plugin with Adminer to one file: https://github.com/FrancoisCapon/LoginToASqlite3DatabaseWithoutCredentialsWithAdminer/blob/master/build-adminer-4-sqlite3-into-one-file.sh

Dieses Kommando räumt eine Sqlite Datenbank auf, killt unnötige Leerzeichen und defragmentiert den Datenbank File.

In meinem Fall war die DB nach dem löschen einer relativ großen Table immer noch auf ca 20MB, das hat mich doch stutzig gemacht und zu diesem Kommando geführt.
Nachdem ich es ausgeführt hatte, war der File dann tatsächlich auf 2MB geschrumpft!

Sollte man vielleicht nicht im laufendem Betrieb machen und als nächstes schau ich mir dann AUTO_VACUUM an.

Ein paar Krücken gibts aber schon, zB bei Transaktionen (die MySql im Regelfall gar nicht kann ;)).
Ich benutze die in diesem Fall für multiple Inserts, um da Performance rauszuschlagen.

Über diese bin ich letztens noch gestolpert:

1. Es ist keine gute Idee Transaktionen zu stückeln und sequentiell abzuarbeiten.(warum auch immer man auf diese Idee kommt ;))
besser ist: alle Queries zu buffern und dann in einer Transaktion auszuführen.
Denn Transaktionen locken die DB und nach meiner Erfahrung kann das PHP SQLiteDatabase Object den Datenbank Cursor nicht richtig schließen.
Das führt dann zu sowas: “cannot start a transaction within a transaction”

Folgender Code:

for ($i = 0 ; $i < count($data) ; $i++) {
	$q='BEGIN;';
	$q.="INSERT INTO ".$this->table." (bla) VALUES ('blub');";
	$q.='COMMIT;';	
	$this->_db->query($q);
}

wird also nicht klappen.

Bei PDO gibt es da wohl bessere Unterstützung für Transaktionen.
Das PHP SQLiteDatabase Object ist da etwas kryptisch.

2. ->query() mag keine Transaktionen, ->queryExec() jedoch schon.
Wahrscheinlich deswegen :

SQLite führt Mehrfach-Anfragen, die durch Semikolon getrennt wurden, aus, so dass Sie Anfragen ausführen können, die aus einer Datei oder über ein Skript geladen wurden. Wie auch immer, das funktioniert nur, wenn das Ergebins der Anfrage nicht benutzt wird. Sollte es doch genutzt werden, wird nur die erste SQL-Anfrage der Liste ausgeführt. Die Funktion sqlite_exec() wird immer Mehrfach-Anfragen ausführen.

Wenn Mehrfach-Anfrage ausgeführt werden, wird die Funktion im Fehlerfall FALSE zurückgeben, anderenfalls jedoch ein undefiniertes Ergebnis (das kann, sollte die Anfrage gelingen, TRUE oder ein Ergebnis-Handle sein).

Also ->queryExec() kanns und ->query kanns irgendwie nicht.
Dort würde nur der erste query ausgeführt und der Rest stillschweigend ignoriert, d.h. die Anweisung gibt true zurück.
Es würde also viele Tupel -unbemerkt- verlorengehen.

Folgender Code hingegen klappt dann:

$q='';
$this->_db->queryExec('BEGIN;');
for ($i = 0 ; $i < count($data) ; $i++) {
	$q.="INSERT INTO ".$this->table." (bla) VALUES ('blub');";
}
$this->_db->queryExec($q);
$this->_db->queryExec('COMMIT;');

Diese Seite war dabei übrigens recht hilfreich:
http://www.ordix.de/ORDIXNews/1_2004/unix_linux_2.html

Ja krass, gar kein Framework benutzt hier! ;)

Falls man sich mal fragt wie man multiple Inserts mit symfony hinkriegt, fängt man an zu googlen und stößt schnell auf dieses Snippet.

Und bevor man da rumeiert und das auf zB Sqlite umschreibt, einfach mal Propel Transaktionen anschauen:

$con = Propel::getConnection();
$con->beginTransaction();

foreach ($temp as $item) {

$blog = new Blogs();
$blog->setTitle($title);

$blog->save($con);

}

$con->commit();

Klappt super, zumindest mit Sqlite bei mir hier.