Важно: я не ищу альтернативу phpMyAdmin, так как SQL DDL предполагается держать в файлах, а не конструировать в стиле phpMyAdmin через веб-интерфейс!

Как назвать искомое мной -- прямо не знаю, ну пусть это будет скрипт.

Язык программирования скрипта не очень важен -- даже и Хаскель пойдет. Но если будет выбор, то лучше все же что-то привычное: С++/java/C#/С (именно с такими приоритетами).

Пример: возможность зайти на урл вроде такого:

http://example.com/db?action=edit&token=mysecret&SQL=select&...

Результат: если токен подходящий (т.е. соответствует авторизованному пользователю, и у пользователя есть права на доступ к id=123), то скрипт  выдаёт страницу, в которой все поля записи показываются, причем каждое в своем виджете (например, если какое-то текстовое поле означает адрес картинки, то показывается эта картинка, а не текст). Далее пользователь может отредактировать и сохранить запись.

Если же токен неподходящий, то скрипт выдает соответствующие страницы ошибок (желательно кастомизируемые).

Что неприемлемо: если инфа о соответствии виджетов полям будет хранится языково-зависимым образом, например в виде исходного текста с определением кучи классов на языке скрипта (однако реализация виджетов в скрипте будет на языке скрипта -- а как же иначе?). В остальном вопрос "как определяется виджет для поля" скрипт решает сам, например, беря (поле, таблица,базы_данных, имя_виджета) из таблицы БД, или из json, или же, прости меня Макаронный Монстр, из xml-файла.

Пример как неприемлемо:

class mydb::mytable::myfield1: public db_image { };
class mydb::mytable::myfield2: public db_text { };
class mydb::mytable::myfield3: public db_number { };

Пример как можно:

<widgets>
<assign db="mydb" table="mytable" field="myfield1" widget="db_image" />
<assign db="mydb" table="mytable" field="myfield2" widget="db_text" />
<assign db="mydb" table="mytable" field="myfield3" widget="db_number" />
</widgets>

Перечислю фичи:

1. Виджеты ко всем полям с возможностью показа и редактирования. В том числе виджеты для таблиц с отношением "внешний ключ".

2. Шаблоны страниц, но не слишком сложные, или, альтернативно, вызов функции полноценного ЯП для формирования страницы из виджетов.

3. Аутентификация/авторизация (юзера, пароли, токены, права, роли) -- или хотя бы только токены.

4. Файлы (можно хранить в БД или ФС по выбору библиотеки); желательно удаление по счётчику ссылок на них =0.

Замечания:

1. Роутинг и другие вещи полезны, но не входят в понятие "минимализм".

2. Токен, понятно, лучше передавать кукой, но в гет-параметрах он тоже должен восприниматься.

3. Создавать/удалять токены, регистрировать юзеров и т.п. скрипт не обязан. Он должн только знать, откуда их брать, и как их проверять.

4. Тут на самом деле ещё кое-какие проектировочные решения должны быть (например, как быть с виджетами на несколько полей), но это не принципиально.