I Spent 20 Years on PHP/MySQL. Then My Stack Broke.

I didn’t set out to build a database client. I set out to find one. That search lasted two years and ended with MyD1.

The Era of Stability

I’m Tanguy (pronounced tahn-GEE — it’s French). For most of my career, my stack was simple and completely stable: PHP on the backend, MySQL for the database, Apache in front. The tooling ecosystem around it was mature, battle-tested, and quietly excellent.

I knew where everything was. I knew how to debug it. I knew which tools to reach for. It was boring in the best possible way.

And at the center of that stack, for managing every database I ever touched, was one tool: Adminer.

Adminer Was Genius

If you’ve never used Adminer, the pitch sounds too simple to be true: a single PHP file, under 500KB, that you drop into any directory on your server. Open it in a browser, enter your database credentials, and you have a full database client. Tables, queries, exports, imports, schema editing — all of it, from a file smaller than a JPEG.

No installation. No dependencies beyond PHP. No configuration. No account. Just a file.

For the PHP/MySQL world, this was the perfect tool. It worked in shared hosting environments where you couldn’t install anything. It worked in Docker containers. It worked anywhere PHP ran, which was everywhere. Its predecessor, phpMyAdmin, had become bloated and slow — Adminer was the answer that felt like someone actually thought about the problem.

I used it for everything. Every client project, every personal project, every time I needed to look at data without writing a query from scratch. Adminer was as much a part of my workflow as my text editor.

Then Adminer Started to Slip

Slowly, almost imperceptibly, something changed. New PHP versions shipped, and Adminer lagged. A deprecation warning here, a broken feature there. The release cadence that had been quiet-but-steady went silent. Months passed between commits. Then most of a year.

A fork appeared — AdminerEvo — to patch the compatibility gaps. I watched it. The activity was sporadic. It felt like a project being held together by people who depended on it too much to let it die, but who also didn’t have the bandwidth to truly revive it.

Adminer wasn’t dead. But it wasn’t growing either. It had become a piece of infrastructure in maintenance mode, sustained by inertia.

That was fine — for a while. Because my own stack hadn’t changed yet.

Then My Stack Changed

The shift wasn’t dramatic. It happened project by project, over maybe two years. New work started coming in that wasn’t PHP. It was SvelteKit, Node.js, Vite. A Python backend here, a serverless function there. TypeScript everywhere.

I kept expecting to reach for Adminer out of habit. And then one day I realized: I hadn’t. There was no Apache running locally. No PHP runtime in the project. Adminer’s entire premise — “it runs wherever PHP runs” — had become irrelevant because PHP wasn’t running anywhere in my workflow anymore.

The backbone of my database management workflow, the tool I’d relied on for nearly two decades, had quietly become incompatible with the way I worked.

The Search

I needed a new database client. My requirements were simple, or so I thought:

• Works with MySQL (still some legacy projects)
• Works with PostgreSQL (new projects were landing here)
• Works with SQLite (local development, embedded databases)
• Connects to Cloudflare D1 — this new edge database I was starting to use everywhere
• Native macOS app — no JVM, no Electron, no web wrapper

The search was quick. The disappointment was slower.

TablePlus is genuinely good — fast, native-feeling, clean UI. But it connects over native database protocols. Cloudflare D1 is REST-API-only. TablePlus simply can’t connect to it. I kept staring at the connection dialog hoping I’d missed something. I hadn’t.

DBeaver is powerful but it’s a Java application. Hundreds of megabytes at rest. The startup time. The way it makes my MacBook fans spin up just from idling. You can feel the JVM under everything, like doing delicate work with oven mitts.

DB Browser for SQLite is fine for SQLite specifically, but it’s one database, and the interface hasn’t been redesigned since about 2012. And it definitely doesn’t speak D1.

DataGrip is excellent at what it does, but $229/year for a tool I use in my spare time feels wrong. And it’s still a JVM app. And it still can’t connect to D1.

The pattern became clear: every good tool predated the REST-API-only database model. They were all built for the world of TCP sockets and wire protocols. Cloudflare D1 had invented a new connection paradigm, and the entire ecosystem of database clients had been left behind overnight.

Cloudflare D1 Was the Final Straw

I’d been following D1 since its beta. The pitch was compelling — SQLite at the edge, globally replicated, Workers-native, generous free tier. I started using it for new projects.

And the only way to interact with it was:

wrangler d1 execute my-db --command "SELECT * FROM users LIMIT 10"

That’s it. One command. JSON output in your terminal. Scroll to find the column you care about. Run another command. Scroll again.

The Cloudflare dashboard had a D1 tab with a basic query editor. It was better than nothing — but not by much. No table browser worth the name. No inline editing. No query history. No export. A round trip to a web page for every interaction.

I was working with a database that could serve reads from 330 data centers simultaneously, and my management workflow was copy-pasting JSON from a terminal window.

Nobody Was Building It

I kept waiting for someone to ship the obvious tool. A native macOS client that spoke the D1 REST API, had a real table browser, and didn’t require a JVM or Electron. It seemed like something that should exist.

Six months passed. Then a year. I watched GitHub, ProductHunt, Hacker News. There were a few browser extensions, a couple of web-based tools, nothing native, nothing that felt right.

At some point the waiting stopped feeling reasonable. The tool I needed wasn’t coming. The choice was to keep working around the gap or close it.

So I Built It

I started MyD1 as a weekend project that got out of hand in the best possible way. Pure SwiftUI — no frameworks I didn’t write myself, no Electron, nothing that would compromise the native macOS experience I wanted. A REST adapter for Cloudflare D1. Native wire protocols for MySQL and PostgreSQL. Direct file access for SQLite.

And an AI Agent that reads your actual schema and writes SQL for you, because it’s 2026 and that should be table stakes for any database tool.

The twenty-year detour through PHP/MySQL — Adminer, phpMyAdmin, the whole era — gave me a strong intuition for what a database client should feel like. Fast. Obvious. Out of your way. I tried to build that, for the stack that actually exists today.

Here’s a full breakdown of why the tooling gap exists and what MyD1 does about it. And if you want to see it for yourself: download MyD1 and connect to your first database in 30 seconds.

Related: The Best Databases of 2026 Have the Worst Tooling · D1 Launched Without a Client. We Built One. · Managing Cloudflare D1 Without the Terminal