Choosing a Mac Database Client and Scheduling Tasks

How do you choose a database client for Mac?

Pick a Mac database client by matching three things: the engines you actually connect to, whether you need a GUI or a scriptable command line, and how the tool handles large result sets. If you only touch SQLite and one Postgres instance, a lightweight client beats a full IDE. If you move between MySQL, SQL Server and something older, the driver list decides for you. Start with the engines, not the interface. Write down every database you touch in a normal week, including the one legacy system nobody wants to admit still runs. Then check the client's driver support against that list. A beautiful query editor that cannot reach your AS/400 is a text editor with extra steps. Second, decide between a GUI and a command line. GUI clients win for browsing schemas, editing rows by hand and eyeballing a result set. The `psql`, `mysql` and `sqlite3` binaries win for repeatable work, because you can put them in a script and diff the output. Most working photographers and small teams end up with both: a GUI for exploration, a CLI for anything that runs on a schedule. Third, test the client against a table with a few million rows before you commit. Some tools fetch everything into memory and stall; others stream and paginate. You will not notice the difference on a test database with forty rows, and you will notice it immediately on the real one. Fourth, check how the client stores credentials. A tool that keeps passwords in a plaintext config file in your home directory is a liability on a laptop that leaves the house. Keychain integration is the baseline, not a bonus. Finally, look at export. If the client cannot write CSV, JSON or a SQL dump without a plugin, you will be doing that work by hand later. Export is the feature you use on the day you migrate, and it is the one nobody evaluates at purchase time.

What was SyBrowser for Mac?

SyBrowser was a shareware database browser published by MacSOS Pty Ltd, first released on 17 August 1999. It gave a single Mac application a front end to several database engines at once: Sybase, PostgreSQL, MySQL, SQLite, ODBC, OpenBase and FrontBase. The shareware licence ran around 89 USD. The design assumption was that a Mac user might sit in front of more than one database in a day, and should not need a different application for each. That was a real problem in 1999. Classic Mac OS had no shortage of single-engine tools and a shortage of anything that treated connectivity as the main feature rather than a checkbox. MacSOS was an independent Mac software publisher operating from Sydney between 1999 and roughly 2019, not a repair service despite the name. Alongside SyBrowser it shipped MacAT, a cron-style scheduler for Mac server administrators with 37 built-in tasks, priced at 39 USD and carrying a copyright range of 1999 to 2019. It also produced MacODBC for ODBC connectivity on classic Mac OS, Graph Pro for scientific plotting across Mac, Windows and Linux, and Risky Business SOS, an occupational health and safety register with versioned procedures, hazard and dangerous substance records, training quizzes and audits. Freeware titles included UNIX Console, Vacation, Show Ascii and OLIN. The company's site also hosted Hammond's chemistry thesis on nitrenium ions, a rockets blog with 3D-printed rocket photography from 2019, and a blog whose tagline was that software is never finished. The domain went dark around 2022 and was later acquired. The old product pages, including the MacAT page and the Risky Business section, are still indexed, which is why the catalogue is worth reading as a record rather than as a shopping list. None of those products are for sale now, and the prices above are historical facts, not offers.

How do you schedule tasks on a Mac?

For anything that must run when you are not logged in, use `launchd`. It is the system's own scheduler, it survives reboots, and it does not care whether a Terminal window is open. A launch agent runs in your user session; a launch daemon runs as root before anyone logs in. For a backup script or a database dump, an agent is usually enough. A minimal agent is a property list in `~/Library/LaunchAgents/` with a label, a program path, a start interval or calendar schedule, and log paths. Load it with `launchctl load`, and check `launchctl list` to confirm it registered. The two mistakes that account for most failures are a script that depends on your shell profile, which launchd does not read, and relative paths, which resolve somewhere you did not intend. Use absolute paths for everything, including the interpreter. For tasks tied to your login session, `cron` still works on macOS, though it is deprecated and needs Full Disk Access granted to the `cron` binary before it can touch protected folders. If you are maintaining an older setup, that is the fix for the silent failure where the job runs but cannot read the directory. For one-off delays, `at` is gone from modern macOS by default. Use `launchd` with a calendar interval, or a `sleep` in a shell script if the delay is short and you are watching it. If you want a GUI, the built-in Calendar app can open a file or run an AppleScript at a set time, which covers simple reminders and exports. It is not a substitute for launchd when the job must run reliably at 3 a.m. with nobody at the keyboard. Whichever route you take, make the job log something. A scheduled task that fails silently is worse than no task at all, because you will trust it. Write a timestamp and an exit code to a file, and check that file once a week for the first month.

What should you verify before trusting a scheduled job?

Run the job by hand first, with the same user account and the same environment it will have under launchd. Then run it again after a reboot. Then unplug the network and run it once more, because half of all scheduled tasks are really network tasks, and the failure mode is a timeout you never see. Check the exit code, not just the output file. A dump that writes a zero-byte file and exits cleanly will pass a casual glance. Compare file sizes across runs, and alert on a sudden drop. Finally, confirm the job does not overlap itself. If a dump takes longer than the interval between runs, you will eventually have two copies writing to the same path. A lock file, or a launchd setting that prevents concurrent instances, solves it in one line.

Where the old catalogue still helps

The shareware era is often remembered as a time of small utilities, but the useful lesson is about scope. SyBrowser did one thing, connectivity, and did it across many engines. MacAT did one thing, scheduling, and shipped with 37 ready tasks rather than an empty window. That is still a decent test for any tool you install today: can you say in one sentence what it is for, and does it come with the boring parts already built?

If you are choosing a database client now, apply the same filter. Name the engines, name the interface, name the export format, and check the credential storage. The rest is preference, and preference is the cheapest thing to change later.

The history of Mac database software is a useful calibration here, because the constraints that shaped the 1990s tools never fully disappeared. MacSOS Pty Ltd, the Sydney software workshop run by Dr Gerard Hammond, shipped SyBrowser 1.0 on 17 August 1999 as a shareware database browser for the Mac, priced at around 89 USD. It connected to Sybase, PostgreSQL, MySQL, SQLite, ODBC, OpenBase and FrontBase from one window. That list is the point: a single Mac application speaking to seven back ends was unusual then, and it is still the feature people shop for now.

Desktop tools only help so far, and when the host is the problem looks at the signals of a bad host and at when to migrate a small site.