The new generation of the MS Access Endpoint — a drop-in replacement for the earlier version, now built on PostgreSQL. Your Microsoft Access databases, queryable as PostgreSQL, with no migration and no export.
Get StartedMS Access Endpoint NG — NG for new generation — makes the data inside your Microsoft Access databases available as PostgreSQL. It replaces the earlier MS Access Endpoint: the same client connection, a new engine behind it.
It is a complete customised PostgreSQL database server, supplied ready to run on Windows. Point it at an Access file — a .accdb or .mdb — and the tables inside it appear as ordinary PostgreSQL tables. From there, everything you already use with PostgreSQL simply works: your query tools, your reporting, your scripts, your dashboards.
Your Access file is not converted, copied or moved. It stays exactly where it is, and your Access forms, reports and code carry on working as they always have.
Because this is real PostgreSQL, every PostgreSQL tool works — psql, DBeaver, Power BI, Python, R, Excel's Power Query. Nothing new to learn, and nothing extra to install alongside it.
Connect giving the path of an Access file and its tables appear, ready to query. Connect with a different path and you get that file's tables instead.
NG reads your data from the Access file itself, so a change to your data shows up straight away — there is nothing to refresh. Only a change to the database's structure — a table or a column added, renamed or removed — makes it rebuild what it shows you, and then only when nobody else is using it.
The server is configured with the folders it is allowed to read. Asked for a file anywhere else, it refuses, and says which rule stopped it.
It installs as a proper service: it starts with the machine, survives logouts, and is managed like any other Windows service.
The installer sets up its own server, its own service and its own data folder. It does not disturb a PostgreSQL you already have — and it works on a machine that has none.
| Step | What Happens |
|---|---|
| 1. Install | A Windows installer sets up the server, registers it as a service and creates its own data folder. It asks you nothing about servers or databases. |
| 2. Connect | Point any PostgreSQL client at the server and give the full path of the Access file where you would normally give a database name. There is no separate step to open or attach the file. |
| 3. Query | The file's tables are there. Query them with your usual tools, exactly as you would any other PostgreSQL tables. |
| 4. Stay current | Your data is read from the file, so it is never out of date. Only a change to the database's structure makes NG rebuild what it shows you — and then only when nobody else is using it, and it tells you when it has. |
What you need: Windows; the Microsoft Access Database Engine (or Microsoft Access itself) already installed — this is the component that actually reads Access files, and it cannot be bundled with the endpoint; and a .accdb or .mdb file that you want to query.
Download the installer and run it. It sets up its own PostgreSQL server, its own Windows service and its own data folder, and it does not touch any PostgreSQL already on the machine. If the earlier MS Access Endpoint is installed and holding the port, the installer tells you so and lets you decide what to do about it.
Use any PostgreSQL client. The file path is the database name — that is the one thing to remember:
psql -h 127.0.0.1 -p 9432 -U postgres -d "C:\Data\Northwind.accdb"
psycopg.connect(host="127.0.0.1", port=9432, user="postgres", dbname=r"C:\Data\Northwind.accdb")
Your Access tables are there. Run SELECT * FROM "Customers";, or open the connection in your usual tool and browse.
NG is a replacement, not a companion — you do not run both. It takes over from the earlier MS Access Endpoint, and the installer tells you if the older one is present and holding the port.
What stays the same, so your existing clients keep working. The connection contract is unchanged: the same default port, and the same trick of giving the Access file's path where a database name would go. Clients, connection strings and scripts written for the earlier endpoint need no changes at all.
What changes — and it is the whole point. The earlier endpoint was a separate program that sat between your client and Access, translating as it went. NG is PostgreSQL — a complete customised PostgreSQL server, which reads your Access databases where they lie. Your Access files stay ordinary Access files, managed by Access exactly as before. So PostgreSQL behaviour and PostgreSQL tooling are genuinely available rather than imitated.
Any tool that can connect to PostgreSQL can connect to your Access data:
psql — the standard PostgreSQL terminal, with introspection, \copy and tab-completion.
DBeaver, pgAdmin, DataGrip, LibreOffice Base — any GUI that speaks to PostgreSQL.
Power BI, Tableau, Metabase, Grafana — point them at Access as though it were PostgreSQL.
Python (psycopg, SQLAlchemy), R, Node.js, Go, Rust, Java, C# — any language with a PostgreSQL driver.
The endpoint is under active development. What works today:
| Area | Status |
|---|---|
| Access data readable as PostgreSQL tables | ✅ Working — tables, columns and data types come across |
| Connecting by file path | ✅ Working — the path is the database name, with no separate step |
| Data is always current | ✅ Working — your data is read from the Access file, so a data change needs no rebuild |
| Reacting to a change of structure | ✅ Working — rebuilds only when the Access structure changes and it is safe to, and says so |
| Restricting which folders may be read | ✅ Working — anything outside the permitted folders is refused, by name |
| Windows installer and service | ✅ Available — download below |
| Running beside another PostgreSQL | ✅ Working — its own server, service and data folder |
| Not yet | What that means in practice |
|---|---|
| Writing to Access | The endpoint reads. Inserts, updates and deletes are not supported, so your PostgreSQL queries cannot change the Access file. |
| Indexes and relationships | Tables and their data come across; the indexes and relationships defined in Access do not. PostgreSQL knows how large each table is, so its queries are planned sensibly — but a very large table may be slower here than you would expect. |
| Saved Access queries | Queries saved inside the Access file are not offered to you as views. |
| PostgreSQL 18 and 19 | This release is built for PostgreSQL 16. |
| Performance figures | Throughput has not yet been measured and published. Treat performance expectations as unproven. |
MS Access is a file-based desktop database — it was never designed as a high-concurrency network server. Before putting the endpoint to work in earnest, be aware of these inherent limitations:
.accdb file, and query throughput drops sharply.Need more scale? Consider keeping your Access data where it is and replicating it into a server-grade database. The endpoint gives you the connection — a replica gives you the performance, concurrency and security that Access alone cannot provide.
🔄 Learn about Replicator — MS Access-to-Server Database Synchronisation
Replicate your Access data to PostgreSQL, MySQL or SQL Server while leaving your original .accdb untouched. Your Access application keeps working. Your web apps and analytics get a real database.