Why Microsoft Access never came to Mac

The search that always disappoints

Every month, more than a thousand people type "microsoft access for mac" into Google. They expect a download link. They get workarounds, old forum threads, and a long list of things that are not Access.

The search has looked the same for over a decade. Microsoft ported Word, Excel, PowerPoint, and Outlook to macOS across three decades. They never ported Access. Access is the only major Office application that has never had a Mac release.

In 2008, Office for Mac briefly included a limited utility called "Database." It could connect to SQL Server and SharePoint lists, but it had no form designer, no local storage engine, and no VBA. Microsoft removed it in the next release and never brought it back.

The omission is architectural, and it goes back to the early 1990s.

Four reasons Access stayed on Windows

Access launched in November 1992 as part of a project codenamed Cirrus. Microsoft sold it for $99, undercutting Paradox and dBASE by hundreds of dollars. It shipped over one million copies in its first ten months. From day one, every layer of the application assumed Windows.

1. The Jet / ACE engine

Access stores data through the Microsoft Jet Database Engine, later replaced by the Access Connectivity Engine (ACE). Both were written in C++ against Win32 memory management, Windows file I/O locks, and Windows collation tables. The engine has no macOS build and never had one.

The .mdb and .accdb file formats are private to this engine. No third-party library reads them with full fidelity. Even tools that parse the format (MDB Tools on Linux, for example) cannot run the queries, macros, or forms stored inside the file. The data is portable in theory. The application layer is not.

2. COM, OLE, and ActiveX

Access forms rely on the Component Object Model (COM) and Object Linking and Embedding (OLE). ActiveX controls, Windows common dialogs, and third-party OCX components are wired into the form surface. None of these subsystems exist on macOS.

When Microsoft ported Word and Excel, they could replace COM automation with their own Cocoa bridges. Access forms are different. Every control on the surface is a COM object with event bindings, property bags, and OLE containers. Replacing them would mean redesigning the form runtime, the part of Access that users interact with most.

3. The VBA runtime

Visual Basic for Applications inside Access calls Windows DLLs, Windows API functions, and the Windows Registry directly. Porting this runtime would have required a full Windows compatibility layer on macOS: a VM inside the app.

Microsoft did port VBA to Mac for Word and Excel, but those apps use VBA mostly for document macros. Access uses VBA as its primary programming language. Thousands of production databases contain tens of thousands of lines of VBA that call Win32 functions by address. A Mac port would have broken all of them.

4. Economic incentive to stay

Through the 1990s and 2000s, Access kept enterprise workgroups on Windows PCs and Windows Server file shares. A shared .mdb on a network drive meant every user in the workgroup needed a Windows PC. Porting Access to the Mac would have removed one of the stronger reasons for departments to stay on Windows.

By the time Microsoft shifted strategy toward cloud services (SharePoint, Power Apps, Dataverse), the incentive to port Access had disappeared entirely. Microsoft now steers new users toward browser-based tools. Access remains on Windows as a legacy product, still updated but no longer a growth priority.

The Microsoft Mac Business Unit (MacBU) spent years porting the rest of Office. They left Access behind because porting it meant rewriting it from scratch, and the business case argued against the effort.

For the deeper story of how desktop databases evolved from dBASE in 1979 through Bento and into the present, see the full 45-year history.

What Mac users do instead (and what it costs)

Each workaround either costs too much, lives entirely in a browser, or drops you into a developer console.

Virtual machines: Parallels, VMware Fusion, UTM

You can install Windows inside a VM and run Access there. This works. It also means a VM license, a Windows license, and an Office 365 subscription, totaling roughly $250 per year. On a MacBook, the VM uses significant RAM and battery to keep two operating systems running. Every time you want to open a form, you boot Windows first.

FileMaker Pro

FileMaker runs natively on macOS and has real relational capabilities: a visual relationship graph, a scripting engine, and a form layout canvas. It costs $594 per year. That price targets enterprise teams with consultants and multi-user servers. For a freelancer tracking clients or a small shop managing inventory, it is more tool than the job requires.

Airtable

Airtable rebuilt the database as a cloud spreadsheet with typed columns and relational links. Plans run $20 to $45 per user per month. Every record lives on Airtable's servers. When your connection drops or AWS has a bad day, your data is out of reach.

There are no offline forms, no local files, and no way to keep records on your own disk. For a deeper comparison, see the Airtable alternatives page.

LibreOffice Base

LibreOffice Base is free and open-source. It requires a Java runtime, and its interface has not kept pace with macOS conventions. Mac support is limited. For users who left Access because they left Windows, Base can feel like a lateral move.

Tap Forms

Tap Forms started as a native Mac app that felt close to the old Bento spirit. It has since moved to a subscription model, joining the pattern that pushed users away from cloud tools in the first place.

For a full comparison of these options side by side, see the Access for Mac alternatives page.

The closest thing Mac ever had

In January 2008, FileMaker Inc. released Bento, a $49 personal database built from scratch for Mac OS X Leopard. Bento skipped relational complexity in favor of drag-and-drop card trays, customizable themes, and sync with Apple Address Book and iCal. It sold well. In 2010, it came to iPad and became one of the top-rated tablet productivity apps that year.

Bento had limits. It stored data in a single library file, which could not be split across projects. It had no relational links between tables. It did not export cleanly to anything except CSV. But for freelancers, students, and small-business owners, those limits mattered less than the price and the experience.

On September 30, 2013, FileMaker Inc. discontinued Bento. The most common explanation: at $49, small-business owners and freelancers were buying Bento instead of FileMaker Pro, which cost $299 to $499. FileMaker Inc. never confirmed the reason publicly.

The cancellation left tens of thousands of Mac users without a native personal database. That gap has been open for thirteen years. No one filled it. Apple never built a database into macOS. FileMaker raised its price. The Mac App Store filled with contact managers and note-taking apps, none of which replaced what Bento did: let a non-programmer build a structured database with a form interface.

What Mac users needed all along

The people searching for Access on Mac are searching for a tool, not a brand. They want a desktop app that runs on their operating system, stores data on their disk, and lets them build forms around their records. The workarounds fail because each one drops at least one of those requirements.

A native desktop app

A real application in your dock. It launches in under a second, works offline, and follows macOS interface conventions. A browser tab or a VM cannot do that.

Forms over grids

FileMaker proved in 1985 that data entry belongs in a form, with fields arranged in their natural place on a visual layout. Cloud databases brought back the infinite spreadsheet grid. A Mac database should give you the form back. That means a canvas where you drag fields into place, set widths, and group related data visually, the way a paper form does.

Local file storage

A database project should be a folder on your disk. You should be able to find it in Finder, back it up to any drive, and move it between machines by copying it. If the vendor disappears, your files remain. If your internet goes out, your records are still there.

Dosirak stores schema definitions in TOML files and records in a SQLite database, all inside a regular folder. TOML is a human-readable text format. SQLite is the most widely deployed database engine in the world. Both are open formats. Your data never depends on a proprietary cloud service to be readable.

Agent automation via MCP

An AI agent can read the schema, query records, and file new entries through the embedded MCP database server. The agent works through a structured protocol against typed fields and relational constraints. Every change goes through your approval before it lands.

This matters because agents work best when they have structured data to read and write. A spreadsheet gives an agent a grid of untyped cells. A relational database gives it named tables, typed fields, and foreign keys. The agent can validate its own output against the schema before it asks you to confirm. For more on why this matters, see why agents need databases.

A database built for the Mac

Dosirak is a local-first desktop database. It runs natively on macOS (Apple Silicon and Intel) and Windows. There is no VM, no browser tab, and no subscription server between you and your records.

A project is a folder. TOML files define the tables, fields, and views. SQLite stores the records. The desktop app opens each record as a form with fields in a computed responsive grid, alongside list and card views. The form is a first-class surface, the way it was in FileMaker and Access, before cloud tools replaced it with a spreadsheet row. For more on that shift, see the death of the database form.

Access has capabilities Dosirak does not replicate: a Turing-complete VBA engine, a freeform pixel-positioned report designer, ODBC data sources, and SharePoint integration. If your workflow depends on thousands of lines of VBA, Access is still the right tool.

Dosirak is for the Mac user who needs forms, records, and an agent, and has been waiting since 2013 for their operating system to get a desktop database again. Whether you track customers, inventory, projects, or collections, the workflow is the same: define your tables, arrange your form, and enter your records.

A desktop database for the Mac

Dosirak runs natively on macOS and Windows, keeps records in a folder on your disk, and opens each record as a form. See what Dosirak does.

Questions