Outgrowing Microsoft Access: 2 GB size and multi-user limits

Why a shared Access file stops scaling and what replaces it

A server-based database removes both constraints that a shared Access file runs into: the 2 GB size limit and the file locking that happens when many people open one .accdb file over a network drive. For a self-hosted replacement, the two options to evaluate are Baserow and PostgreSQL with Mathesar. The limits come from the architecture, so compacting or splitting the file only postpones them. In Access, every workstation opens the same file and coordinates through lock files on the share, so a growing file and a growing number of users make each other worse, and a dropped network connection during a write can damage the file. Before you choose, check three things: the current file size and how fast it grows, how many people edit at the same time, and whether the file is mostly tables and forms or a line-of-business system with heavy VBA, queries and reports.

Baserow runs as a web application on PostgreSQL, so people edit records in a browser and the server coordinates their changes. The baserow/baserow Docker image starts an internal PostgreSQL by default, but Baserow highly recommends an external PostgreSQL for production, so plan for that database from the start. PostgreSQL with Mathesar follows the same server-side model with more direct control. Mathesar connects to an existing database or sets one up, and access follows PostgreSQL roles and privileges, so the people who edit a table are the people your database administrator has granted rights to. Mathesar describes itself as in public beta, so test it against your own workload. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a failed primary or switch over by itself. PostgreSQL's high availability documentation explains the building blocks, and you must choose and test an external failover tool.

Use the answer to the structure question to choose. If the database is mostly tables, forms and simple views used by a team in a browser, Baserow is the shorter path, and SSO is available on its Advanced and Enterprise plans with an activated license. If the database is a line-of-business system whose logic lives in queries, VBA and reports, PostgreSQL with Mathesar gives you a database that other applications can also reach, with Mathesar handling everyday editing. Either way, ask the vendor or your implementation partner to test concurrency and file growth against a copy of your real data. Confirm who owns backup, restore and upgrades. PostgreSQL 14 support ends on November 12, 2026, so a new deployment should start on a version that is still supported.

What the size and concurrency constraint requires from a replacement

An Access file hits its ceiling because one file on a network share does the work of a database, a lock manager and a permissions layer at once. A replacement has to split those jobs across a server, so each requirement below is something you can test before committing to a platform.

A data store that is not one file

Records should live in a database server process, not in a single file that every client opens directly. Ask where the data physically sits, how it is written during concurrent edits, and whether a corrupted client session can damage the stored tables. For Baserow, the store is PostgreSQL; for Mathesar, it is the PostgreSQL database you connect to. Confirm both in your own environment with a test load before accepting either.

Concurrent access through a browser or connection

Many users should edit the same tables at once through a browser or a authenticated database connection, not through a shared network drive. Test how the platform handles two people editing the same row, how many simultaneous sessions your target load requires, and whether a connection pooler is needed in front of the database. Record the results, since they replace the file-locking behavior Access users are used to.

Role and privilege control at the database level

Access permissions are applied per user to a file, which weakens once the data is copied or exported. Verify that access rules are enforced by the server, so a user restricted to certain tables or rows cannot bypass the restriction through another tool. For Mathesar, access is based on PostgreSQL roles and privileges. For Baserow, confirm which role and permission features your chosen license tier includes, since some are on paid plans.

Room to grow past the file ceiling

The replacement should have no hard file-size cap that forces another migration later. Ask the vendor or community to show the largest deployment they support, and test your own growth curve against storage, memory and backup windows. PostgreSQL can be run with replicas for reads and a standby for failover, but automatic failover needs external tooling, so confirm who builds and operates that layer.

Backups and upgrades that do not depend on one desktop

A backup should be a server-side job that does not depend on someone copying a file from a laptop. Define the recovery point you need and test a restore on a separate machine. For upgrades, PostgreSQL's major releases have fixed support end dates, so plan a route for each upgrade and confirm the restore path works before you need it.

What the 2 GB limit and network-share locking mean in practice

The 2 GB ceiling matters less for the size of today's data than for the headroom you have left, and that headroom shrinks faster than most teams expect. Every new table, index, form and linked attachment adds to the single .accdb file, and Access does not split data across files for you. Once the file approaches the limit, the risk is not only failed saves but also a database that becomes slow to compact and repair, because those operations rewrite the whole file. Check the current file size, the largest tables and how much of the size comes from attachment fields, which store binary content inside the database. Confirm the exact ceiling, and how it applies to your Access version and file format, in Microsoft's current documentation before you plan around a number.

Multi-user sharing over a network drive depends on file locking and on how each client behaves, not on a central server coordinating the work. Each workstation opens the shared file directly, and Access uses lock records inside the file to tell users which records are being edited. When a client crashes, loses its network connection or is closed without a clean exit, locks can be left behind and the file can need repair. Concurrency also degrades as more people write at once, and a single shared file on a network path is sensitive to drive mapping, antivirus scanning and Wi-Fi drops. Ask whether your team has seen corrupted or locked-record incidents, how often compaction is run and who is responsible for it. Confirm current multi-user behavior and supported configurations with Microsoft, because no supplied fact describes them. A server-based database moves locking and transactions onto the database engine, which is the main reason the rest of this page looks at Baserow and PostgreSQL.

Which self-hosted options handle concurrency and growth

This table compares how Baserow and PostgreSQL with Mathesar handle many concurrent users, growing data and access control, plus where Grist fits. Read each row against your own user count, data volume and whether you need SSO or audit logs, since several of these answers depend on your license choice and your team's operating skills.

Capability	Baserow	PostgreSQL with Mathesar
Storage engine	PostgreSQL, with an internal database by default in the single container image	PostgreSQL directly, so tables, schemas and roles you already manage are the same ones users see
Browser access for many users	Browser-based multi-user application served from a server, with no shared network file	Browser-based interface served from a server, with no shared network file
Growth path	Docker Compose with separate backend and frontend images, or Kubernetes with Helm for horizontal scaling; external PostgreSQL recommended for production	Scales with the PostgreSQL deployment you choose, including replication and connection pooling; Mathesar itself is a web layer on top
Access control	Role-based permissions and audit logs are listed for the paid Advanced tier; confirm exact scope for self-hosted licenses	Access follows PostgreSQL roles and privileges, using existing roles or roles created in Mathesar
SSO for self-hosted users	SAML and OpenID Connect are available on Advanced and Enterprise with an activated license	PostgreSQL supports certificate, LDAP, GSSAPI and OAuth 2.0 authentication methods; confirm what Mathesar exposes at login
Maturity of the front end	Established, with a broader application builder, dashboards and automations	Public beta; confirm the features you need in the current release before committing
Calculation-heavy work	Suited to relational records with grid, form and automation views	Relational work with SQL views; Grist is a smaller option for formula-heavy models, covered on its own page
Engine maintenance	Your team operates the Baserow application, its database and its upgrades	Your team operates PostgreSQL, including minor updates and major upgrades, which PostgreSQL documents as a routine task

Choosing between Baserow and PostgreSQL with Mathesar by situation

This situation fits an Access file that is mainly tables, relationships and data entry screens, used by a team that works in a browser. Baserow is built around that workload. It offers a grid interface, forms, an application builder for portals and dashboards, and automations, and it is headless and API first, so other tools can read the same records later. Its self-hosted edition is open core: non-premium and non-enterprise features fall under the MIT License, while SSO on the Advanced and Enterprise plans requires an activated license.

Editing model: Baserow keeps the spreadsheet-style editing that Access users know, with forms for entry and the application builder for read-only or guided views.
Automations: Baserow automations replace many simple Access macros, such as notifications or field updates triggered by a record change.
Access control: Role-based permissions and audit logs are listed for the Advanced cloud plan, so confirm which of these the self-hosted license type you choose includes.
Import path: Baserow's Airtable importer does not cover this case, but its CSV, Excel, XML and JSON import covers Access exports.
Limits to test: Formula, lookup and rollup fields need a manual rebuild, so count how many Access calculations you depend on.

Before committing, ask your vendor or test instance to confirm which license type includes the permissions and SSO you need.

Deploying the chosen database on your own servers

This sequence moves an Access database that has outgrown its file into a server-based database that your own team runs, with a tested import, concurrent editing checks and a plan for backups and upgrades. The result is a production system where the 2 GB file limit and shared-file locking no longer apply.

Size and inventory the Access files
Start by recording the size of each Access file, the number of tables and rows in each, and the attachments and linked tables it holds. Note which users open the file, from where, and at what times, because this shapes the server sizing and the access model. Ask the database owner to confirm which forms, reports and macros depend on each table. The step is done when you have a written inventory that lists every table, its approximate row count, its attachments and the people who depend on it.
Choose the target platform
Select Baserow when the team mainly needs a shared spreadsheet-style database with forms, views and browser access for many users. Select PostgreSQL with Mathesar when the data is relational, the team wants direct database control, and PostgreSQL roles should govern access. Confirm with your security team that the chosen platform's license and features match your requirements, especially for single sign-on. The step is done when a decision record names the platform, the reasons and the owner.
Provision a server with external PostgreSQL
Provision a Linux server in your own data center or cloud account, sized from the inventory, and install PostgreSQL on it or on a dedicated database host. Baserow's Docker image bundles an internal PostgreSQL and Redis by default, but Baserow highly recommends an external PostgreSQL for production, so plan for that from the start. Set up storage for database files and attachments, and confirm that backups can reach them. The step is done when PostgreSQL accepts connections from the application host and the server passes your internal baseline checks.
Deploy with Docker Compose or Kubernetes
For a single-team instance, deploy Baserow with Docker Compose, which runs separate backend and web-frontend images. For horizontally scaled deployments, use the Kubernetes setup with Helm, which Baserow also documents. Point the deployment at the external PostgreSQL and set the public URL and TLS certificate for your domain. Keep the configuration and secrets in your own version-controlled repository. The step is done when the web application loads over HTTPS from an internal browser and a test user can sign in.
Configure single sign-on only where the license allows
Enable single sign-on only after confirming that your license type includes it. Baserow lists SAML, OAuth 2.0 providers and generic OpenID Connect on the Advanced and Enterprise plans with an activated license. If you run the Free or Premium setup without that feature, plan for local accounts or a different access model, and confirm the choice with your identity team. For Mathesar, access follows PostgreSQL roles, so align those roles with your directory groups. The step is done when a test user signs in through the intended method and an account without the right group cannot reach the data.
Import data and test concurrent editing
Import the tables from the inventory, using the Airtable importer for Airtable sources or CSV, Excel, XML or JSON import for Access exports. Rebuild relationships, field types and views, then check row counts and attachments against the Access source. Ask several testers to edit the same records at the same time and record any conflicts, slow screens or lost changes. Repeat the test with the number of users you expect at peak. The step is done when counts match, the attachments open, and the concurrency test produces a written result that your business owner accepts.
Plan backups and PostgreSQL maintenance
Define backups for the PostgreSQL data and the attachment store, and test a restore into a separate environment before go-live. PostgreSQL's continuous archiving and point-in-time recovery documentation describes the options you should evaluate with your database administrator. Schedule minor updates, which replace executables and require a restart without changing the storage format, and plan major upgrades with pg_upgrade, logical replication or a dump and restore. PostgreSQL 14 support ends on November 12, 2026, so plan any move off that version early. The step is done when a restore test succeeds and an upgrade calendar is approved.
Design failover and connection handling
PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a failed primary or promote a standby on its own. Choose an external failover tool, confirm that its behavior matches your recovery objectives, and test a controlled switchover. If many application connections strain the database, evaluate PgBouncer as a connection pooler and measure its effect before adopting it. The step is done when a failover test completes in a lab environment and the runbook lists who initiates each action.

Evidence that the new database handles load and recovery

A reviewer or internal auditor will not accept a migrated database on its word. The cards below list the evidence that shows a server-based database handles concurrent users, recovers from failure and stays patched, and they name the checks to run before the Access file is retired.

Documented architecture

Write down which components run where: the Baserow or Mathesar application tier, the PostgreSQL primary and any standby, the reverse proxy, the network zones and the location of stored attachments. Record the hosting environment inside your own cloud account, data center or air-gapped network. Reviewers will check that this diagram matches what is running, so regenerate it after every change to the topology.

Tested backup and point-in-time recovery

A backup that has never been restored is not evidence. Document the base backup schedule and WAL archiving, then run a restore into a separate environment and time how long it takes to reach a chosen point in time. Keep the restore log, the recovered row counts and the attachment checks together. Ask your DeployOpen team to write the runbook and capture the results.

Concurrency test results

Test with the people who will actually use the database, not with synthetic traffic alone. Run representative users editing the same tables at once, including bulk imports, filtered views and attachment uploads, and record errors, lock waits and response times. Compare results against the Access shared-file pattern they replace. Connection pooling with PgBouncer is worth testing if many clients connect at once.

PostgreSQL version and support dates

Record the exact PostgreSQL major and minor version in production and its end-of-support date. PostgreSQL 14 is supported until November 12, 2026, while 15 runs to November 11, 2027, 16 to November 9, 2028, 17 to November 8, 2029 and 18 to November 14, 2030. Plan the upgrade before the date that applies to your version, and confirm the dates against the official policy when you file the evidence.

Access role mappings

Map every Access user group and form-level permission to a named PostgreSQL role or a Baserow permission group. Mathesar uses PostgreSQL roles and privileges, so the role grants become the audit trail for who can read or change each table. Export the mapping as a controlled document, review it with the data owners and keep a dated copy for each access review.

Patch and upgrade records

Keep a log of each minor update, major upgrade and Baserow or Mathesar release applied, with the date, the tester and the rollback plan. PostgreSQL minor releases do not change the storage format, but major upgrades need pg_upgrade, a dump and restore, or logical replication. Record which method you used and the downtime observed, so an auditor can trace each change to its approval.

Questions buyers ask before replacing a shared Access database

How much effort and cost depend on the size and number of Access objects?

Effort rises with the number of tables, relationships, queries, forms, reports and VBA modules, more than with the raw file size. A database that is large only because of attachments or a long history of records is usually simpler to move than one with dozens of forms and macros that encode business rules. The cost components are the data export and import, the rebuild of forms and reports, the rewrite of VBA or macro logic, testing with real users, and the server and PostgreSQL setup. Ask for an inventory of every object in the file before agreeing on a quote, because that inventory is what makes the scope written and comparable.

How long does a migration take and what drives the duration?

The duration depends on the object inventory, how many users must be trained, how much business logic lives in VBA, and how many parallel reviews the business requires. Data volume matters less than the number of rules to reproduce and verify. Attachments need their own transfer and check, and multivalued or lookup fields need a decision on how they map to the target. Timelines should come from a written scope and a test cycle, not from a generic estimate. Ask any provider to show the phases, the acceptance tests and the cutover window before accepting a schedule.

Can our team migrate the database without outside help?

A team with a database administrator, someone who knows the Access logic, and a person who can run Docker or manage a Linux server can often do the core work in-house. The harder parts are reproducing VBA behavior, setting access rules that match existing permissions, and validating data after import. Outside help is most useful for the server build, the mapping of data types and keys, and the acceptance testing. Be clear about which of these your staff can own, and agree on handover documentation so that the system can be run after the engagement ends.

Which option suits many concurrent users, Baserow or PostgreSQL with Mathesar?

Both replace a shared network file with a server-based database, which removes the file locking and corruption risks of a shared Access file. Baserow is the better fit when teams need browser-based forms, views, automations and portals with role-based access, and it can be deployed with an external PostgreSQL for production. PostgreSQL with Mathesar fits when the data is a line-of-business system and access should follow PostgreSQL roles and privileges. Concurrency depends on the server sizing, the connection pooling and the workload, so ask for a load test against your own user counts.

What does the business owner need to provide during the migration?

The business owner must confirm which reports, forms and calculations are still used, who owns each table, and which rules are authoritative when records conflict. They also need to approve the access model, set the retention rules for old records and attachments, and sign off the acceptance tests. Without these decisions, the technical team will rebuild everything, including unused objects. Plan a short review cadence with the owner so that questions are answered in days, not in the final week before cutover.

Does Mathesar's public beta status matter for a production database?

Yes, it matters, and it should shape the decision. The Mathesar project describes itself as in public beta, with version 0.12.0 tagged on July 2, 2026. For a production system, confirm the current release status, the upgrade path, the supported PostgreSQL versions for the release you choose, and the support arrangements. PostgreSQL itself is a mature database, so the data layer is not in beta, but the interface layer is. Many teams mitigate this by keeping the data in PostgreSQL, testing the Mathesar release in staging, and pinning versions until acceptance testing is complete.

Where to go next in the migration

Read the sibling pages in this order: the export guide first, then the comparison that matches your database, then the migration guide for the destination you choose. The export guide explains what Access hands over and what it drops, including one object per export, attachments, OLE objects, flattened multivalued fields and lookups exported as IDs. The comparison pages cover the decisions made before any data moves: Access against Baserow for browser access by many users, Access against Grist for calculation-heavy databases, and Access against PostgreSQL with Mathesar for line-of-business systems that need PostgreSQL roles. The migration guides then cover the mechanics. The Baserow guide covers relationships, forms, reports and replacing macros with automations, while the PostgreSQL and Mathesar guide covers data types, keys, views and role setup.

Export matters most for attachments and multivalued fields, because those are where a migrated database can look complete while meaning has been lost. A multivalued field flattened into one text column still shows values, but the links between records are gone. A lookup exported as an ID forces someone to rebuild the displayed value. Attachments and OLE objects are not carried in the export at all, so their files must be extracted and linked separately. Before exporting, list every table with its attachment, multivalued and lookup fields and record the row count for each. After import, reconcile the counts and spot-check records that hold files and multiple values. Treat any mismatch as a blocker before the Access file is retired.

Let each importer's documented scope set the destination. Mathesar imports CSV files with comma, tab, semicolon, colon or pipe delimiters, so records move as text and any file content needs a separate route into its file data type. Baserow's pricing page lists CSV, Excel, XML and JSON import, but its documented Airtable importer is a different path, so ask Baserow in writing how Access attachments and multivalued values will land in its file and link fields. Run a pilot on the largest table that holds files. Also confirm the versions you will deploy: Mathesar is in public beta, and PostgreSQL 14 support ends November 12, 2026, so new deployments should start on 17 or 18. The Mathesar import documentation lists the supported delimiters.

How DeployOpen works on this

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, so a move off a shared Access file can run on a server you control. We start by agreeing a written scope for the Access databases, users and data that must move, then build, test and document the replacement with your team.

How we scope

Inventory every Access table, linked source, form, report and macro that depends on the shared file
Record concurrent users, peak edit periods and largest tables to size the target platform
Agree in writing which tables move to Baserow and which move to PostgreSQL with Mathesar
Engagements are fixed-scope, with deliverables and timelines confirmed before work begins

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network
Configure an external PostgreSQL database for production, with authentication and role design agreed up front
Import data in stages and check record counts, attachments and relationships against the Access source
Run security testing on the deployed platform and document the findings and fixes

How we hand over

Provide documentation covering architecture, access roles, backup configuration and restore steps
Walk your administrators and power users through editing, reporting and permission changes
Set up backups and a tested restore procedure before cutover, so recovery does not depend on one person
Prepare the evidence your compliance assessors may ask for, while independent auditors issue any formal opinion

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainers can cover PostgreSQL minor updates and planned major version upgrades on your schedule
Confirm with us which support tier, response expectations and upgrade cadence apply before signing
Ask for a written quote that follows directly from the agreed scope, since we do not publish a price list