Access
PostgreSQL

Access to PostgreSQL Converter

Move from Access file databases to PostgreSQL on-prem or cloud-hosted. Schema conversion, type mapping, queries to views, and optional two-way sync.

Access to PostgreSQL migration moves tables from a local .mdb or .accdb file into a server database.

A common reason is to move shared data beyond Access's 2 GB single-file limit; the hard part is separating the database tables from the application logic that lived in the same file.

What DBConvert does on this path: handles the Access-to-PostgreSQL move as a repeatable desktop workflow:

  • Reads Access .mdb and .accdb files, including secured databases that need WorkGroups credentials.
  • Maps Access fields, indexes, relationships, and supported query objects into PostgreSQL-compatible tables and views.
  • Writes to PostgreSQL, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, or Supabase.

What it does not do: DBConvert does not convert an Access application into a PostgreSQL application. Forms, reports, macros, VBA, and front-end workflows should be handled separately from the database migration.

Which DBConvert tool fits?

Use DBConvert for the planned migration; use DBSync when Access must remain operational while PostgreSQL is introduced.

DBConvert for Access → PostgreSQL

One-time conversion with source-file selection, type mapping review, Access query-to-view handling, saved sessions, direct PostgreSQL targets, or a PostgreSQL dump file for DBA-controlled restore.

DBSync for Access ↔ PostgreSQL

Repeat synchronization when the Access database must stay in use during a staged cutover. Use bidirectional sync only when table ownership and conflict-handling rules are clear; see database synchronization concepts for the underlying workflow.

Need more context? Compare DBConvert and DBSync side by side →

How DBConvert handles the Access → PostgreSQL differences

Access is both a database file and an application platform; PostgreSQL is only the backend. DBConvert moves the database side with sensible defaults that you can review or override per table; the application objects stay in Access or are rebuilt outside the migration.

Field type mapping

Access type PostgreSQL type
AutoNumberGENERATED ... AS IDENTITY
Yes/Noboolean
Long Text / Memotext
Currencynumeric(19,4)
Date/Timetimestamp
Hyperlinktext
OLE Object / Attachmentbytea

Lookup fields keep their underlying value type; the lookup display is an Access UI concept and lives in the front end.

Driver and Windows requirements

Connects through Microsoft Jet (32-bit) or ACE OLE DB (32-bit or 64-bit) on Windows - DBConvert ships in matching architectures, so picking the build that matches the installed Office / Access architecture is a one-click decision, not a debugging session.

Keys, indexes, and relationships

Preserves Access primary keys, foreign keys, and indexes on the PostgreSQL target so referential integrity is in force from the first load. Index names are made unique within schema (PostgreSQL requires schema-unique index names); Access defaults that PostgreSQL parses differently are normalized in the wizard.

Access queries → PostgreSQL views

Translates supported Access SELECT and UNION queries into PostgreSQL views during the migration. Parameter queries, action queries (UPDATE/DELETE), and queries that use Access-specific functions are not translated - rebuild those in PostgreSQL views or in the new application layer.

Forms, reports, macros, VBA - out of scope

These are part of the Access application, not the database. DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. Forms and reports continue to work as a front end against linked PostgreSQL tables, or are rebuilt in a web / .NET / BI front end as a separate workstream.

Choosing the migration route

Access to PostgreSQL projects split into three different jobs: moving tables, keeping an Access front end, or rebuilding the application.

Route Best fit Boundary
DBConvert / DBSync Desktop migration from .mdb or .accdb files into PostgreSQL, with type mapping, query-to-view handling, saved sessions, and optional staged synchronization. Moves database objects and data; Access forms, reports, macros, and VBA remain outside the database migration.
PostgreSQL ODBC / linked tables Keeping the existing Access front end while PostgreSQL becomes the shared backend for tables. Requires Access form/report testing, primary keys on linked tables, and careful handling of Access queries that call local VBA or form controls.
Custom export scripts or ETL Projects where the Access application is being redesigned and the team wants a developer-owned extraction pipeline. You own the parsing, type mapping, attachments/OLE handling, retries, and validation checks.

Supported versions

  • MS Access .mdb (Jet) and .accdb (ACE) files
  • WorkGroups credentials and linked tables
  • PostgreSQL 8.x through 17.x
  • Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, Supabase
  • PostgreSQL schemas (public, custom schemas)

Supported in this path

Source Access
Target PostgreSQL
Microsoft Access PostgreSQL Amazon RDS / Aurora for PostgreSQL Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Supabase
Access

All Access Tools

Other directions and pairs
PostgreSQL

All PostgreSQL Tools

Migration & sync options

Reverse Conversion

PostgreSQL to Access

Using Access to PostgreSQL Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to Access source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to Access source database from DBConvert

Access source

Select the source .mdb or .accdb file. If it uses Access WorkGroups, enable WorkGroups and enter those credentials on the source step.

2

Connect to PostgreSQL destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to PostgreSQL target database from DBConvert

PostgreSQL target

Connect to self-hosted PostgreSQL, Amazon RDS / Aurora, Google Cloud SQL, or another supported PostgreSQL target.

More guides for Access ↔ PostgreSQL

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options - pick tables, fields, indices, views.
  • Issue detection - the built-in checker flags integrity problems before migration starts.
  • Execute - commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI - rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3-5, software features, command-line mode, scheduler, and system requirements.

See all features