Mac database clients and task scheduling

Choosing a database client for macOS comes down to three things: the engines you must reach, whether you want a graphical browser or a terminal, and how the tool is maintained. If you connect to one engine only, the vendor's own client is usually enough. If you move between PostgreSQL, MySQL, SQLite and something older, a general client earns its place. The history of mac database software is a useful reminder that this category has been rewritten several times, and that some tools outlived the engines they were built for.

How to choose a database client for Mac?

Start with a list of the engines you actually touch in a normal week. A client that speaks PostgreSQL and SQLite but not MySQL will not survive contact with a mixed estate. Check the connection methods too: a direct TCP connection, an SSH tunnel, and a socket file are three different setup paths, and not every client handles all three without extra work.

Then decide between a graphical browser and a terminal. A graphical client wins when you inspect schemas, edit rows by hand, or export results for someone else. The terminal wins when you script, when you work on a remote host, and when you want the same commands on your laptop and on the server. Many people keep both: a GUI for reading, the shell for repeating.

Look at how results are presented. Sorting, filtering, copying a result set as CSV, and viewing a large table without freezing the window are the daily operations. A client that renders 200,000 rows in a scrollable grid is doing something different from one that pages them. Neither is wrong, but you should know which you are buying.

Check the release history before you commit. A client last updated three years ago may still work, but drivers move. PostgreSQL, MySQL and SQLite all change their wire protocols or file formats over time, and a client that bundles its own drivers will need updates to keep up. Look for a changelog with dates, not a version number alone.

Consider licensing. Open source clients can be audited and forked; commercial clients usually come with support. For a solo developer, a free client with a paid tier is often enough. For a small IT team, the question is who answers when a connection fails at 9am on a Monday.

Finally, test with your own data before deciding. Import a dump of a real table, run the queries you run every day, and see how the client behaves when a query takes thirty seconds. That test tells you more than any feature list.

What was SyBrowser for Mac?

SyBrowser was a database browser for the classic Mac OS, published by MacSOS Pty Ltd, the Sydney software workshop of Dr Gerard Hammond. Version 1.0 shipped on 17 August 1999 as shareware at around 89 US dollars. It was not a database engine. It was a client: a window onto databases that already existed elsewhere.

The list of engines it could reach was unusually wide for its time. Sybase, PostgreSQL, MySQL, SQLite, ODBC, OpenBase and FrontBase all appear in the product's own documentation. That range mattered in the late 1990s, when a Mac user who needed to look inside a Sybase or OpenBase database had few native options. SyBrowser sat in the same family as MacODBC, MacSOS's connectivity layer for classic Mac OS, which handled the ODBC side of the same problem.

The company behind it operated from 1999 to roughly 2019 and never described itself as a repair service, despite the name. Its catalogue also included MacAT, a cron-style scheduler, Graph Pro, a scientific graphing tool, and Risky Business SOS, an occupational health and safety register with versioned procedures and training quizzes. The domain went dark around 2022 and was later bought and turned into an independent Australian magazine about Mac software, The Menu Bar, which covers tools, maintenance and shareware history.

SyBrowser is a period piece now. It ran on an operating system that no longer exists, and the shareware model that funded it has largely gone. Its interest is in what it shows about the problem: a Mac user with several database engines and no single client that speaks to all of them. That problem has not gone away, it has just moved to new tools.

How to schedule tasks on a Mac?

macOS has two scheduling systems, and the choice between them is mostly about how much control you want.

cron is the older one. It still works, it is documented in the manual pages, and its syntax is the same on macOS as on Linux. A crontab entry has five time fields followed by the command. To run a script every day at 02:30, the line is `30 2 * * * /Users/you/bin/backup.sh`. The catch on macOS is permissions: cron needs Full Disk Access to read parts of the filesystem, and jobs that touch protected folders will fail silently without it. You grant that in System Settings under Privacy and Security.

launchd is Apple's own system, and it is the better choice for anything that must survive sleep, wake and login changes. A launch agent is a property list file in `~/Library/LaunchAgents/` with a label, a program path, and a start interval or calendar schedule. The equivalent of the cron line above uses `StartCalendarInterval` with Hour 2 and Minute 30. Load it with `launchctl load` and check it with `launchctl list`. The advantage is that launchd can run a job when the machine wakes if the scheduled time was missed, which cron cannot do.

For a one-off delay, `at` is not enabled by default on macOS, so most people use `sleep` in a shell command instead. For repeated work tied to file changes, a launchd watch path is more reliable than polling on a timer.

Whichever you pick, log the output. A scheduled job that fails quietly is worse than no job at all. Redirect standard output and standard error to a file with a date in the name, and check that file the first week. MacAT, the 39-dollar scheduler MacSOS sold from 1999 to 2019, handled 37 tasks and was built for server administrators who needed exactly this kind of visibility. The idea has not changed: a schedule you cannot inspect is a schedule you cannot trust.

What should you check before trusting a scheduled job?

Run the command by hand first. If it fails interactively, it will fail on a timer. Then check the environment: cron and launchd start with a minimal PATH, so a script that calls `psql` or `sqlite3` by name may not find it. Use absolute paths.

Confirm the job runs as the user you expect. A launch agent belongs to one account; a launch daemon runs as root and lives in `/Library/LaunchDaemons/`. Mixing them up is a common cause of permission errors.

Finally, decide what happens when the job overlaps with itself. A backup that takes ninety minutes and starts every hour will pile up. launchd will not start a second instance of the same job by default, but cron will. Add a lock file if the work is long.

Where does the old shareware catalogue fit?

The MacSOS catalogue is a record of what small Mac software companies built when the platform had fewer users and fewer tools. SyBrowser, MacAT, MacODBC, Graph Pro and Risky Business SOS were all made by one workshop in Sydney over two decades. The domain's later life as a magazine about Mac tools keeps that record readable, with dated pages on the products and the shareware era around them. For anyone choosing a database client today, it is a reminder to check who made the tool, when, and whether they are still answering.

Mac database clients and task scheduling sit on one side of a familiar divide: macOS ships with launchd and cron, so recurring jobs are configured once and left to run. Windows takes a different route, where scheduled tasks, startup entries and update cycles need periodic attention from the person using the machine. That contrast matters when a household runs both systems. The same discipline that keeps a Mac tidy, checking what launches at login and what runs in the background, reappears on Windows as routine Windows upkeep habits, from startup cleanup to 3-2-1 backups, treated as practical digital education rather than occasional repair.