When Access still fits and when PostgreSQL with Mathesar fits better
Access still fits when one person or a small group works with a database file on a desktop, and PostgreSQL with Mathesar fits better when the data has become a line-of-business system that several teams edit, must stay on the organization's servers, and needs access rules enforced by the database itself. Access is a sound tool for small, desktop-centric databases with a handful of users. Once the file is shared over a network drive by many teams, the decision turns on whether the organization wants a server-based database with PostgreSQL roles and privileges, which Mathesar uses directly for its access control, instead of a shared file that depends on each client's Access installation.
The decision turns on four questions. First, how many people edit records at the same time, and whether that number is growing. Second, how large the file is and how fast it is growing, since a file approaching the 2 GB limit is a signal to plan a server-based move. Third, where the data must reside, because PostgreSQL runs on servers the organization controls and Mathesar is designed to be self-hosted. Fourth, whether the team needs to keep Access forms and VBA logic. Mathesar offers a spreadsheet-like interface, a form builder and a Data Explorer, but it does not run VBA, so macro-driven logic has to be rewritten in the database, in views or in another application layer.
Before choosing, ask the team to list every VBA procedure, form and report the database depends on, and to count the users and the largest tables. If most of the value sits in simple tables that people edit in a grid, PostgreSQL with Mathesar is a strong candidate. If the value sits in complex forms and procedural code that users will not give up, confirm whether the rebuild effort is justified or whether Access should remain a front end for a PostgreSQL back end. For the current release status and supported PostgreSQL versions, check the Mathesar documentation and confirm the versions in your environment before committing.
Which option fits which scenario
This table matches common Access situations to the option that usually fits best, with the reason in each row. Read it against your own file size, user count and governance needs, because the right answer often depends on which constraint is hardest to change. Keeping Access as a front end is sometimes the lower-effort choice, but it leaves the data in a shared file that the limits below still apply to.
| Scenario | Better fit | Reason |
|---|---|---|
| Single-user Access file with simple tables | Keep Access for now, or move to PostgreSQL with Mathesar later | One person editing a small file has little concurrency risk, so migration can wait until a deadline or second user appears |
| Shared file on a network drive | PostgreSQL with Mathesar | A server-based database handles several editors without relying on the shared file, which is the main reason to move data off a network drive |
| Multi-team system needing central access rules | PostgreSQL with Mathesar | Access rules follow PostgreSQL roles and privileges, which are defined once on the server rather than per file |
| Team that depends on Access forms and reports | Keep Access as a front end, or plan a rebuild | Mathesar offers a form builder and spreadsheet-like editing, but Access forms and VBA logic will need to be rebuilt or reconnected |
| Organization requiring data to stay on its own servers | PostgreSQL with Mathesar | Mathesar is self-hostable and PostgreSQL runs wherever you deploy it, so records stay within your infrastructure |
| Database with attachments stored in fields | Confirm before choosing | Access attachments and OLE objects need a separate storage plan on PostgreSQL, so test how each attachment is migrated and displayed |
| Team with heavy VBA automation | Keep Access short term, then plan a rewrite | Business logic in VBA has no direct equivalent in PostgreSQL and Mathesar, so it must be moved into queries, views or application code |
| Database that must survive a server outage | PostgreSQL with Mathesar, with a high availability design | PostgreSQL supports standby servers, but automatic failover needs external tools that your team or partner must select and operate |
How Mathesar changes everyday editing for Access users
Mathesar does not replace Access forms with a one-to-one clone, so the first decision is which Access objects your users actually touch every day. Mathesar connects to an existing PostgreSQL database, including its schemas and tables, and presents them in a *spreadsheet-like* grid for viewing, editing and querying. Users who only add rows, filter records and look up related values will find the grid familiar. Users who rely on Access forms with embedded subforms, calculated controls or macros that validate input will need that logic rebuilt, either as PostgreSQL constraints and triggers or as a form built with Mathesar's form builder. List every form and report in the current file, then mark which ones contain logic that must move to the database and which are simple data entry.
Access permissions do not carry over directly. In Mathesar, access follows PostgreSQL roles and privileges, using roles that already exist in the database or roles you create inside Mathesar. This means a user who can only read a table in PostgreSQL will see it read-only in Mathesar, and an editor's rights are whatever the database grants. Before go-live, write down which Access users need edit rights to which tables, map each group to a PostgreSQL role, and test those grants with a non-administrator account. Confirm with your own environment how Mathesar behaves when a role lacks privileges on a related table, since lookups across tables can expose records that a user did not expect to see.
Mathesar is in public beta, and its releases are still changing. The project's version history shows 0.11.0 and 0.12.0 in 2026, and its documentation describes Mathesar Cloud as in early beta. Treat the forms, the Data Explorer and the file data type as features to verify rather than assume. Load a copy of a representative table, including its largest tables, a few attachments and the edge cases your staff currently handle by hand, then run one full working day of typical edits against it. Record every point where a user has to leave the interface or ask for help, and decide before migration whether those gaps are acceptable.
Where the data lives and who controls access
With PostgreSQL and Mathesar, the database, the application and the access rules all run on servers you choose. The cards below cover where the data sits, how Mathesar is hosted, how PostgreSQL roles and authentication decide who can edit what, how recovery is planned, and which compliance evidence DeployOpen prepares versus what auditors issue.
Data sits on your own server
A shared Access file lives wherever someone copied it, often a network drive that several people open at once. With PostgreSQL, the tables sit on one server you control, and Mathesar is a web layer over that same database. Confirm which host, region and disk encryption you will use, and who holds operating system access to the database server, since that person can read every table regardless of application rules.
Mathesar hosting options
Mathesar documents installation with Docker Compose, or from scratch on Linux, macOS or WSL, plus DigitalOcean and Railway. Choose the option that matches your infrastructure policy. Mathesar Cloud is in early beta, so for regulated data it is not a production hosting choice today. Ask whether your chosen install path is covered by the version you plan to run, and confirm it against the Mathesar documentation before you commit.
Access rules follow PostgreSQL roles
Mathesar does not invent its own permission model. It uses PostgreSQL roles and privileges, either existing roles or roles you create in Mathesar. This means a user who is blocked in Mathesar is also blocked at the database level for direct connections. Map each Access user group to a role, grant the minimum on each table, and test edit rights for every role before users start entering production records.
Authentication method choice
PostgreSQL supports password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth authentication, and PostgreSQL 18 deprecated MD5 passwords in favor of SCRAM. For a database used by staff, the decision is whether users sign in through your directory or through database passwords. Confirm the method in pg_hba.conf, and confirm which methods Mathesar itself accepts for its own login, since the two layers can differ.
Backup and point-in-time recovery
Shared Access files are often protected only by copies made by hand. PostgreSQL supports continuous archiving and point-in-time recovery, which lets you restore to a moment before an accidental mass edit. Decide the recovery point you need, who runs restore tests, and where archives are stored. Restore tests are the only proof that the setup works, so schedule them and record the results.
Compliance evidence and audit scope
DeployOpen can plan the database hardening, role design, backup procedure and access reviews, and prepare the evidence that those controls operate. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies decide whether controls meet a framework. Ask your auditor early which evidence they expect, such as role listings, access review records and restore test logs, so the system is built to produce that evidence from the start.
What running PostgreSQL requires after go-live
Once the Access data sits in PostgreSQL, the database itself becomes a service your team operates. Minor releases are the routine part: they never change the internal storage format, so applying one means replacing the executables and restarting the server. Plan a maintenance window for each one and keep the previous binaries until the restart is verified. Major versions arrive about once a year, and each one is supported for five years. The supported windows are PostgreSQL 14 (to November 12, 2026), 15 (to November 11, 2027), 16 (to November 9, 2028), 17 (to November 8, 2029) and 18 (to November 14, 2030). A cluster on 13 or earlier is already outside support, so confirm which major version you are starting on before go-live.
For major upgrades, choose between a dump and restore, pg_upgrade, or logical replication. Logical replication works across major versions and, according to the PostgreSQL upgrading documentation, allows the switch with only several seconds of downtime, which matters most for a shared line-of-business database. Assign one named owner for upgrade planning, usually the platform or database administrator, and test the chosen path against a copy of production data first. High availability needs a separate decision. Hot standby servers can serve read-only queries, and you can choose synchronous or asynchronous replication. PostgreSQL does not detect a failed primary or promote a standby on its own, so any automatic failover depends on external tooling that your team must select, deploy and test. Confirm that choice with your own infrastructure owner before you rely on it.
Connection handling is the last item to plan. Each Mathesar user session and each reporting tool opens database connections, and many small connections can exhaust a modest server. PgBouncer is a lightweight pooler that sits in front of PostgreSQL and is the usual choice for this. Keep backups and point-in-time recovery under the same owner, since the PostgreSQL continuous archiving documentation covers the archive setup. The role that owns these tasks should be a database administrator with authority over the server, backups and upgrade windows, working alongside whoever manages Mathesar and the PostgreSQL roles.
How a move from Access to PostgreSQL with Mathesar proceeds
The sequence moves Access tables, rules and forms into a PostgreSQL database that Mathesar edits under PostgreSQL roles, with each phase closed by a check the business can sign off. Phases that depend on the reader's environment are marked so they can be scoped before work starts.
Inventory tables, queries, forms and VBA
List every table, query, form, report, macro and VBA module in the Access file, and record who uses each one and how often. This is done jointly by the database owner, the business users and whoever maintains the VBA. The output is a written inventory that marks each object as move as data, rebuild as a view, replace with a Mathesar form, or retire. Confirm the list with the business owner before any export begins, because this inventory is the basis of a fixed-scope quote.
Map data types and keys
Translate each Access field type into a PostgreSQL column type and decide the primary key, foreign keys and required fields for every table. Lookup fields and multivalued fields need a decision about normalizing them into link tables. The output is a schema design document reviewed by the data owner. Check it against a sample of real rows from each table, and note where Access stored values that PostgreSQL will reject, such as mixed types in one column.
Export each table as CSV
Export every table from Access as a CSV file, using the delimiter and encoding chosen in the design. Attachments and OLE objects are not part of a plain CSV export and need a separate plan for storage. The output is one file per table with a row count recorded against the source. Compare counts and a few spot values on each file before moving on, so a silent truncation is caught early.
Import into PostgreSQL
Create the tables in PostgreSQL from the approved design, then load the CSV files in dependency order so parent tables exist before child tables. Mathesar can connect to the database and import CSV data, but the schema should be created deliberately rather than inferred from the file. The output is a loaded database with row counts that match the exports and foreign keys that validate. Record any rows rejected during import and resolve them with the data owner.
Rebuild queries as views and set PostgreSQL roles
Recreate the logic of Access queries as PostgreSQL views, and define PostgreSQL roles that match the groups who use the data today. Mathesar bases its access control on these roles and privileges, so the grants on tables and views determine what each user can see and edit. The output is a role matrix signed off by the data owner and a test in which a user without rights is refused. Ask your security team to review the role design against your access policy.
Configure Mathesar forms and Data Explorer
Connect Mathesar to the database, then set up the tables and views that users will edit, along with form builder screens that replace the Access forms the team relies on. Build Data Explorer queries for the reports that used Access queries and pivot views. The output is a Mathesar instance that shows each role the screens it needs and nothing more. Walk a representative user through their daily tasks and record which Access features still have no equivalent.
Run parallel testing
Run the Access file and the new database side by side for a period agreed in the scope, entering the same transactions in both and comparing results. Reconcile totals and key reports each day, and log every difference with its cause. The output is a defect log with each item closed or accepted by the business owner. The length of this period depends on your processes and should be set in the written scope, not assumed.
Cut over and retire the Access file
Freeze edits in the Access file, run a final export and load, verify row counts and reports, then switch users to Mathesar. Keep the Access file read-only for a fallback period set in advance, and document the rollback steps. The output is a signed cutover record and a retired Access file kept under the retention rule your organization applies. Plan the backup of the PostgreSQL database before cutover, since the new system becomes the system of record.
Questions buyers ask before choosing or hiring help
What drives the cost of moving Access to PostgreSQL with Mathesar?
The cost is driven mostly by the volume of work in the database, not by the software, because PostgreSQL and Mathesar are both free to use under open-source licenses. Costs come from the server and its backups, the time to map Access tables, keys and queries to PostgreSQL, the time to rebuild forms and reports, and the people who review the result. Recurring costs are the server, storage, patching and staff time. One-time costs are the migration and testing. Ask any quote to split these components and to state which Access objects are in scope, such as tables only or also queries, forms and VBA.
How long does an Access to PostgreSQL migration take?
Duration depends on how many tables, how much data, how many queries and forms depend on each other, and how much VBA logic must be redesigned. A database with a few simple tables and no custom code is far quicker to move than one with dozens of linked forms and macros. Ask for a timeline built from a written inventory of the Access file, and check that it includes time for data validation and user acceptance testing, not only the copy itself. This page does not give a fixed duration because none was researched for this scope.
Can our team do the migration internally?
Yes, if someone on the team is comfortable with SQL, PostgreSQL administration and a web application installation. The main steps are exporting each Access table as CSV, creating tables with proper data types and keys, importing the data, setting PostgreSQL roles, and connecting Mathesar. Teams without that experience usually find the hardest part is not the import but reproducing Access validation rules, relationships and the logic in queries and VBA. Ask whether the work includes a knowledge transfer and written runbooks so the internal team can run the system after handover.
What does the work need from our side?
The work needs a named database owner who can approve table design, key choices and access roles, and a group of test users who know the daily tasks in the Access file. Your team also needs to decide where the server runs, who holds administrative access, and how backups are kept. Test users should check real records and reports against the old Access output before cutover. Confirm these responsibilities in the written scope so that signoff points and handover dates are clear to both sides.
How are Access forms, reports and VBA handled?
Access forms and reports do not move as code. Mathesar offers a spreadsheet-like interface, a form builder and a Data Explorer for queries, so everyday data entry and simple reports can be rebuilt there. Logic written in VBA usually has to be redesigned, either as PostgreSQL views, functions or triggers, or in the application layer. Some Access behavior, such as complex printed layouts, may not have a direct equivalent. Ask for an inventory of every form, report, query and macro with a decision recorded for each one.
Do attachments and multivalued fields move cleanly?
Not automatically. Access exports do not carry attachments and OLE objects as ordinary columns, and multivalued fields usually need to be split into related tables. In PostgreSQL, the common approach is a junction table for many-to-many values and separate storage for files, while Mathesar supports a file data type for handling uploaded content. Lookup fields are typically exported as IDs and must be resolved again. Confirm with the migration plan how each attachment and multivalued field is extracted, checked and linked, and ask for a sample reconciliation.
Is Mathesar ready for a production line-of-business system?
Mathesar describes itself as in public beta, and its latest tagged versions at the time of research were 0.12.0 and 0.11.0, so the release status should be checked against the current tags before adoption. PostgreSQL itself is a mature database with supported major versions listed in its versioning policy, so the main risk sits in the interface layer. Ask for a test plan covering upgrades, backup restore and user access, and confirm which PostgreSQL version is supported with the Mathesar release you choose.
When is it worth bringing in a partner?
A partner is worth engaging when the Access database holds regulated or critical data, when many VBA routines need redesign, or when the team lacks time or PostgreSQL skills for the migration. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts. Ongoing support is available as a retainer. Ask for a written scope and a quote that follows from it, because DeployOpen does not publish a price list.
Questions to answer before you commit to a move
Before you commit to moving an Access database to PostgreSQL with Mathesar, run four checks on the database itself. Start with user count and concurrency: count how many people open the file at the same time, not how many have access to it. Access shares a single file, so a handful of editors may work well today while a larger group pushes the file toward corruption and locking problems. Next, check the file size in the front-end and back-end files, and note how many tables hold most of the rows. A large back end is a signal that the data belongs on a server, whatever the front end looks like.
Then measure how much of the database depends on VBA. List every module, form event and macro, and sort them into three groups: logic that only shapes the screen, logic that enforces business rules, and logic that calls other systems. In PostgreSQL, rules belong in constraints, triggers and views, and screen behavior moves to Mathesar's form builder or to another front end. Count the attachments and data residency requirements too: Access stores attachments inside the file, and Mathesar's file data type needs a plan for where those bytes live. Confirm with your legal or privacy team where the data may sit, since Mathesar's self-hosting model keeps the data on your servers only if you deploy it there.
Finally, assess your capacity to run PostgreSQL. Someone must own backups, role management, patching and monitoring, and PostgreSQL does not detect a failed primary or promote a standby on its own, so high availability needs additional tooling. Ask whether that person exists inside your team or whether you will buy it from a partner. Because Mathesar is in public beta, read its current release notes and the version support page before you pick a release, and confirm which PostgreSQL versions the release you choose supports. Treat those answers as the input to your decision, not as settled facts.
How DeployOpen works on this
DeployOpen starts by checking whether your Access database is a candidate for PostgreSQL with Mathesar, then plans the move inside your own infrastructure. The work covers the data, the PostgreSQL roles that replace Access permissions, and the editing workflow your users will rely on every day.
How we scope
- Inventory every table, query, form and report to confirm which objects move to PostgreSQL and which are rebuilt.
- Agree in writing which Access features, such as VBA logic and attachments, are in scope and how each is handled.
- Engagements are fixed-scope, with deliverables and timelines agreed before any work starts, and quoted from that written scope.
How we build
- Deploy PostgreSQL and Mathesar in your own cloud account, data center or air-gapped network, so records stay on your servers.
- Map Access data types and keys to PostgreSQL tables, then load CSV exports and test row counts and relationships against the source.
- Define PostgreSQL roles and privileges that mirror your current Access permissions, and test each role before users are onboarded.
How we hand over
- Document the schema, role model, backup procedure and the list of Access behaviors that no longer apply after the move.
- Walk through Mathesar editing, forms and the Data Explorer with the people who run the database day to day.
- Hand over runbooks for PostgreSQL minor updates and major upgrade planning, so your team can operate the system without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover PostgreSQL version tracking, backup verification and Mathesar upgrades as new releases ship.
- Confirm with us during scoping which support level fits your team, since the retainer scope is set in writing.
